Perlas III. Trucos básicos del Responsive Web Design

Hola, seguimos con el fascículo III, y esta vez toca unos trucos básicos para llevar a cabo un diseño adaptable con fundamento. Sé que estais esperando  dos temas cruciales que todavía no he tocado: las imágenes y la navegación, pero me he acordado de lo que nos decía el profesor de bertsolaritza cuando nos daba clase, “dejad el mejor punto para el final”, y yo que soy una alumna aplicada, le hago caso. Paciencia, todo llegará.

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:

@media all and (min-width: 41em)

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?

body{font-size:62,5%;}

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

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 otra 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:

$(“h1”).fitText(1.4,{minFontSize:’38px’});

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.

Y como lo prometido es deuda, las perlas IV y V se ocuparán de  las imágenes en responsive y veremos los patrones de navegación más interesantes.

Perlas II. Metodología del Responsive Web Design

Buenas noches, como parece que hoy os han interesado las perlas sobre responsive design que publiqué ayer, me comprometo a postear mis apuntes poco a poco. Ayer tomé tres páginas de apuntes, hoy once. Supongo que esto me llevará unos cuantos capítulos, así que está claro que se está gestando un nuevo producto: Perlas responsive por fascículos, pronto en tu kiosko. No puedo dejar de sentir cierta sensación de usurpación, ya que todo el mérito de este contenido es de @htmlboy, pero tengo su permiso de divulgarlo mientras mantenga en secreto la fórmula de la cocacola. Thnx.

Hoy voy a centrarme en algo que nos interesa si trabajamos en responsive, pero que normalmente no se encuentra en los tutoriales, blogs, artículos… La metodología. ¿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.

That´s all folks.

Perlas del responsive web design

Hoy tocaba un workshop que imparte Javier Usobiaga (@htmlboy) de Swwwet sobre Responsive Web Design organizado por Enpresa Digitala.  Estos cursos monodosis me gustan mucho porque nos ahorran muchas horas de estudio, ya que poniendo las bases de la teoría y las buenas prácticas en pocas horas, luego cada uno se puede pelear con el resto, que es como se interiorizan las cosas.

Hoy han sido cuatro horas, y mañana otras tantas, y aunque mañana empecemos a meternos en materia con el código, hoy han caído unas perlas que creo que pueden ser muy útiles para la comunidad. No voy a hacer un resumen de lo que es el diseño responsive, ya que para eso es mejor asistir al workshop o estudiar el millón de documentación que hay por ahí. Haré una lista de los tricks que me han parecido interesantes. Para mí, por lo menos han sido como una revelación.

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:

*{
-webkit-box-sizing: border-box; /* Safari/Chrome, other WebKit */
-moz-box-sizing: border-box; /* Firefox, other Gecko */
box-sizing: border-box; /* Opera/IE 8+ */
}

Este cachito de código reseteará todos los 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:

.img-container img {max-width:100%}

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. 😉

<meta name=”viewport” content=”width=device-width, inicial-scale=1.0″ />

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 rem

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.

Y por hoy eso es todo. La bombillita de la imagen hace referencia a una idea de proyecto que he tenido para el #hackelarre que se va a montar en febrero desde el El comité, pero eso seguramente me dará para otros posts futuros.

Gabon.

Blackberry Jam Sessión, un nombre muy glamuroso

firstComo últimamente no me pierdo un #codesarao, el pasado 17 de noviembre tocaba hackathon de Blackberry en Bilbao, pero mucho más glamuroso es llamarlo Jam Sessión, ni punto de comparación. La web de la organización muy bonita: blackberryjamsessions.com

Básicamente se trataba de desarrollar una aplicación para Blackberry 10 en 12 horas. Toda una apuesta. Tuvimos la suerte de que el organizador fuera Jorge del Casar, y pudimos disfrutar de su presencia y contar con su ayuda en nuestros desarrollos. No me voy a extender demasiado explicando nuestra pequeña aportación a Blackberry pero os diré que fuimos los ganadores y pudimos irnos a casa con una gran sensación de satisfacción y con algún que otro regalito 😉 Os dejo una imagen de la aplicación. Curiosidad: las imágenes han de estar a 356ppp.

Fue un día estupendo, pero sobre todo me encantó trabajar de nuevo con @sormenpills, y recordar la sensación de diseñar a duo, en pleno brainstorming y proceso creativo.  Sólo por eso mereció la pena 1000 veces.

Bueno, y después de asistir al Megathon de Windows y a la Jam Session de Blackberry, creo que a alguien más le toca acercarse a Bilbao, ¿no?. Lo estamos esperando. 😉

Ahí va una foto para ver qué formales empezamos el día.

La galería entera está aquí, de la mano de Desarrolladores Blackberry

Emmet.io, HTML y CSS a la velocidad de la luz

¿Por qué andar si puedes volar?

Emmet es el nuevo kit de plugins (actualización de Zen Coding), que hará que vueles con el código. ¿Usas HTML y CSS en tu día a día? ¿Sí?  pues Emmet es tu nuevo amigo. No lo dudes y dedícale 1 minuto para instalarlo y  5 para hacer tus pruebitas. Después de eso no lo vas a porder soltar. Verás que con unas abreviaturas y una sintaxis muy sencilla e intuitiva podrás generar código HTML como si tus dedos no tocaran el teclado.

La teoría la tienes en el siguiente vídeo emitido el 13 de noviembre pasado, que explica los fundamentos de Emmet paso a paso y de una forma bastante clara:

En este enlace tienes la presentación online: http://www.naknak.me/emmet

La experiencia

Después de la presentación de Zen Coding en #tapcoders tuve la propuesta de presentarlo para desarrolloweb.com en uno de sus programas de #devIO, y yo encantada, cómo no. A falta de dos semanas de la charla, un tweet comentaba que Zen Coding se había actualizado y que de hecho había cambiado hasta de nombre. Alerta, Alerta!!! Había que actualizarse. Estudiar, practicar y  preparar la nueva presentación. Cómo siempre de reto en reto. Las horas de los fines de semana siguientes se me fueron en la biblioteca y el resultado es esta presentación. Espero que os guste y que sobre todo os sea muy útil, como lo ha sido para mí.

HTML 5: Soporte en navegadores

Soy fan number one del HTML 5 y el CSS3 que nos permite crear cosas que llavamos soñándo desde años. Pero como no todo el campo es orégano, el standar todavía no se ha cerrado y la implementación está siendo desigual, como desigual está siendo el soporte en navegadores.

Esto es algo que nos lleva a una lucha diaria con el tan deseado por unos y el tan temido por otros cross browser. Y digo temido porque todavía sigo teniendo pesadillas con el cliente que exige que su página se vea al pixel en el navegador de su oficina que no se ha actualizado desde el origen de los tiempos.

Nos quedan tres alternativas:

  1. Seguir maquetando las webs en XHTML y esperar hasta que todos los navegadores soporten HTML5.
  2. Utilizar HTML 5 y esperar a que todos los que utilizan navegadores antiguos se den cuenta de que se están perdiendo algo y se actualicen.
  3. Utilizar HTML 5 y buscarnos la vida para que los despistados de los navegadores obsoletos no se pierdan lo bueno.

Cada uno que elija.

En fin, me encantaría quedarme con la segunda opción, sobre todo porque ahorraría muchísimo tiempo para dedicarlo en mejorar el desarrollo, pero al final siempre acabo en la batalla de la tercera alternativa: probando, testeando, buscando polyfills para que todos se queden tranquilos, y mi conciencia también.

Estos últimos meses me he hecho con algunos recursos que me vienen bien para esta tarea de preparar la web para distintos navegadores, y me gustaría compartirlos por si a alguien le puede ayudar en su propia lucha 😉

Can I use

Esta es la web referencial para ver el soporte que tiene en la actualidad cada elemento de HTML y CSS.  Y digo en la actualidad, porque lo tienen al día, e incluso con predicciones de futuro cercano y futuro lejano. Todo un lujo.

http://caniuse.com/

HTML 5 Shiv

Este pequeño script hará que los navegadores que no soporten las etiquetas HTML 5 las entiendan. Se pone en el <head> y ya está, una cosa menos de la que preocuparnos.

<!--[if lt IE 9]>
<script src="dist/html5shiv.js"></script>
<![endif]-->

http://code.google.com/p/html5shiv/

Modernizr

Librería JavaScript que detecta la compatibilidad del navegador con HTML5 y CSS3

http://modernizr.com

Polyffils

Esta palabra tan bonita quiere decir hack, los recursos que utilicemos para que nuestro desarrollo se vea bien en otro navegador sin soporte se denominan así.

Iba a hacer una lista de los más útiles, pero como no es muy productivo reinventar la rueda os dejo un enlace MUST que ha creado Paul Irish http://paulirish.com/ que tiene que estar en los marcadores de cada uno de nosotros.

https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-Polyfills

En siguientes posts explicaré los que yo he utilizado hasta el momento.

Estaría bien que contribuyerais nombrando los polyfills que usais vosotros, para que podamos tener feedback entre todos y podamos aprender más.

Zen Coding hará que vueles con el HTML y CSS

Esta semana pasada he tenido el placer de impartir una master class en @tapquo sobre Zen Coding dentro de las sesiones de #tapCoders.

Suena muy bien eso del Zen, muy relajante y new age, pero  ¿qué es el Zen Coding?

Es un método de abreviaturas que te permite volar con el código HTML y CSS. ¿Qué desarrollador@ web tiene todo el tiempo del mundo para trabajar en su web tranquilamente y pulirla y pulirla hasta que queda satisfech@?  Siempre andamos  con las deadlines torturándonos y esa es la dura realidad.  Queremos volar con el teclado para que las manos vayan a la velocidad de nuestro cerebro, pero no siempre lo conseguimos.

¿Por qué? Porque para escribir  una lista de dos líneas tenemos que poner:

<div class=”item”>

    <ul>

        <li>First item</li>

        <li>Second</li>

    </ul>

</div>

Abrir, cerrar, no te olvides de las comillas, de cerrar la ul… un trabajo mecánico que nos hace perder el foco donde tiene que estar: en el propio desarrollo.

Pues el Zen Coding viene a solucionarnos este tema porque ahora div.item>ul>li*2 se convertirá en esa lista en un abrir y cerrar de ojos.

¿Quieres saber más? Aquí tienes el enlace de la presentación de la master class y conviértete en un maestro Zen del front-end.

Esta sesión fue la inauguración de #tapCoders, una iniciativa para la continua formación y actualización de desarrolladores web que comparten sus conocimientos con la comunidad. Felicito al equipo de tapquo por su iniciativa. Por mi parte sólo me queda agradecer que contaran conmigo, ya que ha sido una experiencia muy positiva para mí. Contad conmigo cuando queráis: Compartir es el camino.

Foto: @sormenpills

Todo empezó con un tweet: Hackathon Windows 8

Megathon Windows 8 de Bilbao

Todo empezó con un tweet… jajajja. Hoy en día parece que twittear un artículo interesante u opinar sobre algo te convierte en un@ sabi@ del tema. El “problema” viene cuando te dicen: eso está muy bien, ¿serías capaz de explicarlo en una charla? Ups… pues ¡por supuesto! Y claro, te pones a estudiar como si no hubiera un mañana, porque está claro que es distinto tener una opinión sobre algo a ser capaz de explicarlo de una manera medianamente profesional sobre un tema técnico. Y ahí que me encontré en el Megathon de Windows 8 de Bilbao, dando la charla sobre el diseño de aplicaciones Windows 8. Todo un reto. Me entusiasma encontrarme con gente que cree en la gente y confía en que lo vas a hacer bien. No hay mejor motivación que ver que los demás piensan que eres capaz.

Y así, como quien no quiere la cosa, nos pasamos tres días inmersos en charlas de formación y diseñando/programando nuestras aplicaciones. Una experiencia para repetir.

Os dejo el enlace de la charla que di ese día.

Siendo consciente de que no todos hemos nacido para “convencer” a las masas, aquí estoy yo, con mis pequeñas propuestas de colaboración, con la cabeza llena de ideas e interrogantes. Buscar los propios límites nunca es fácil, porque sabes que si los encuentras llegará la frustración y un golpe con la realidad, pero como ahora está de moda decir: hay que intentar salir de tu zona de confort. Y en ello estoy.

Fotos: Blog de Josue Yeray: http://geeks.ms/blogs/jyeray/archive/2012/09/11/evento-hackathon-windows-8-en-bilbao.aspx y @asiermarkes

Horma bizijjak

Roman Ondak Tate museumen

Sarrittan museuetan ikusten doguzen gauzak harritu biharrian bere horretan izten gaittuez, hotz. Baina honek ez, denporia da ez nebala zeozer hain potentia ikusten. Gela huts bat zelan bete leike hutsik mantenduz? Roman Ondakek erantzuna emon dotso honeri. Bixiko presentzijja lortu dau 90.000 sinadura inguru batuz. Pentsona guzti horren esentzijja hor geratu da, eta bibra etxen dau. Danak alkarregaz, bat gorago bestia beherako, eta ikusten danez, gehijjenak tamaño standar bategaz ;P Ixarren konstelaziñoien antzerako lan honek, artista sentidu erain dittuz milaka pertsona. Ze modu edarra jentia artera hurreratzeko, ezta? Neuk be nahi dot juan firmaten (Penia aurreko udan ixan zala)

Creando marca #nak

Me encanta crear marca, aunque no tenga nada que vender. No soy freelance , ni busco clientes, pero me encanta tener un logo, una imagen, un proyecto que englobe todo lo que hago, y aprovechar cualquier momento tonto para repartir alguna tarjeta por ahí. Supongo que será una manía adquirida de cuando creamos Lea multimedia, un proyecto que duró más de lo debido por nostalgia y aprendimos más de lo imaginado por escarmientos. Algún día hablaré sobre ese proyecto loco, que también se podría haber llamado tranquilamente: “échate a la piscina, que no hay agua”.

Tengo dominios comprados de nombres que me gustan que nunca he usado que se han convertido en idea de marca con su logo… pura fachada. No tienen ningún proyecto por detrás, ningún objetivo. Bueno, algún objetivo ya cumplen: me dan satisfacción. Es algo parecido a hacer la casa por el tejado, la última capa de barniz de un huevo vacío.

Me encanta el proceso creativo, espero escribir más sobre este tema. Es una ola que arrasa con todas las ideas que tenías en fase de boceto. El proceso te roba el raciocinio y sólo puedes seguir por el camino que te indica, es un torbellino que no puedes quitarte de la cabeza.

Esta primavera sin venir mucho a cuento me atrapó una de estas tormentas y me entró otra vez la fiebre de crearme ‘otra’ marca, aparte de @nabaroa que estaba cogiendo su forma. Así apareció #nak un poco de la nada. No es muy original: Naiara Abaroa Kortabitarte. Utilizar la iniciales como logo supongo que no me da muchos puntos como creativa, pero me encanta su sonoridad. Nak, nak. Es fuerte, y corto. Y de ahí a tener el logo, las tarjetas, la web, el blog… puro proceso creativo.

Ahí os dejo un ejemplo de lo que es a día de hoy #nak. No creo que tarde mucho tiempo en variarlo, ya que no puedo quitarme de encima la manía de aburrirme de mis diseños casi antes de que toquen la luz. En fin, algo saldrá.