Monthly Archives: December 2012

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