lunes, 16 de mayo de 2016

Diseño responsive. Media Queries.

Siguiendo con el tema del diseño responsive, hay que hablar de uno de sus pilares. Las media queries.
Las media queries, tienen su origen en los media types disponible en CSS2.

Con los media types, se podían definir diferentes estilos dependiendo del medio en el que se esté "visualizando" la página.

Por ejemplo:
<link href="main.css" media="all" rel="stylesheet" type="text/css"></link>
<link href="print.css" media="print" rel="stylesheet" type="text/css"></link>
Aquí estamos indicando que queremos usar main.css en todos los casos ("all") pero en el caso concreto de la impresora ("print") utilizaremos print.css

Los diferentes tipos de media son

  • all: Valor por defecto. Aplica a todos los media
  • print: Aplica en la impresión (y en la vista previa si está disponible)
  • screen: Pantalla de ordenador
  • tv: Televisores.

Las media queries evolucionan de los media type, proporcionando información no solo del dispositivo, sino también de ciertas características del mismo como por ejemplo el ancho.

En el ejemplo de la entrada anterior, ¿cómo hacemos que el contenido se recoloque en función al tamaño del dispositivo?
Pues un ejemplo puede ser este:



<!DOCTYPE html>
<html>
<head>
<meta name="viewport" content="width=device-width" />
<title>Ejemplo Media Queries</title>
<style>
@media screen and (min-width: 480px){
#derecha { width: 98%; float:none }
#izquierda { width: 98%; float:none }
}

@media screen and (min-width: 800px){
#derecha { width: 49%; float:left }
#izquierda { width: 49%; float:left }
} </style>
</head>
<body>

<div id="derecha" style="background-color:aqua;">
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aenean commodo ligula eget dolor. Aenean massa. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Donec quam felis, ultricies nec, pellentesque eu, pretium quis, sem. Nulla consequat massa quis enim. Donec pede justo, fringilla vel, aliquet nec, vulputate eget, arcu. In enim justo, rhoncus ut, imperdiet a, venenatis vitae, justo. Nullam dictum felis eu pede mollis pretium. Integer tincidunt. Cras dapibus. Vivamus elementum semper nisi. Aenean vulputate eleifend tellus. Aenean leo ligula, porttitor eu, consequat vitae, eleifend ac, enim. Aliquam lorem ante, dapibus in, viverra quis, feugiat a, tellus. Phasellus viverra nulla ut metus varius laoreet. Quisque rutrum. Aenean imperdiet. Etiam ultricies nisi vel augue. Curabitur ullamcorper ultricies nisi. Nam eget dui. Etiam rhoncus. Maecenas tempus, tellus eget condimentum rhoncus, sem quam semper libero, sit amet adipiscing sem neque sed ipsum. Nam quam nunc, blandit vel, luctus pulvinar, hendrerit id, lorem. Maecenas nec odio et ante tincidunt tempus. Donec vitae sapien ut libero venenatis faucibus. Nullam quis ante. Etiam sit amet orci eget eros faucibus tincidunt. Duis leo. Sed fringilla mauris sit amet nibh. Donec sodales sagittis magna. Sed consequat, leo eget bibendum sodales, augue velit cursus nunc,
</div>
<div id="izquierda">
Li Europan lingues es membres del sam familie. Lor separat existentie es un myth. Por scientie, musica, sport etc, litot Europa usa li sam vocabular. Li lingues differe solmen in li grammatica, li pronunciation e li plu commun vocabules. Omnicos directe al desirabilite de un nov lingua franca: On refusa continuar payar custosi traductores. At solmen va esser necessi far uniform grammatica, pronunciation e plu sommun paroles. Ma quande lingues coalesce, li grammatica del resultant lingue es plu simplic e regulari quam ti del coalescent lingues. Li nov lingua franca va esser plu simplic e regulari quam li existent Europan lingues. It va esser tam simplic quam Occidental in fact, it va esser Occidental. A un Angleso it va semblar un simplificat Angles, quam un skeptic Cambridge amico dit me que Occidental es.Li Europan lingues es membres del sam familie. Lor separat existentie es un myth. Por scientie, musica, sport etc, litot Europa usa li sam vocabular. Li lingues differe solmen in li grammatica, li pronunciation e li plu commun vocabules. Omnicos directe al desirabilite de un nov lingua franca: On refusa continuar payar custosi traductores. At solmen va esser necessi far uniform grammatica, pronunciation e plu sommun paroles. </div>
</body>
</html>

Como veis, para los dispositivos más pequeños (mínimo 480px de ancho) las capas se verán una encima de otra; cuando el ancho supere los 800px, las capas se verán una al lado de otra. Hemos conseguido que el contenido se recoloque dependiendo de la anchura del dispositivo.

Para más información, podéis visitar este enlane: https://www.w3.org/TR/css3-mediaqueries/
Aquí os dejo un enlace con sitios web que utilizan media queries http://mediaqueri.es/

domingo, 8 de mayo de 2016

Diseño web adaptable

Últimamente me he dado cuenta de que el desarrollo de front-end es más "agradecido" que el desarrollo de back-end.
En el back-end hay sesudas discusiones sobre el uso de IoC, capas, .... que sólo tenemos los desarrolladores o arquitectos de software.
El front-end es más vistoso y el usuario es lo que termina viendo.

Cuántas veces hemos hecho un desarrollo bien organizado, con sus capas bien hechas, bien orgullosos de nuestro trabajo ... y cuando lo ve el usuario pone de cara de besugo diciendo "Esto qué es??!!" (Por favor, decidme que os pasado!)

Hay que decir que el front-end es algo más que poner iconos bonitos y colorines vistosos; hay que hacer una experiencia de usuario agradable, bonito y usable. He de reconocer de que es uno de mis puntos débiles, pero intento controlar la parte técnica, esperando que algún día mis niveles de dopamina lleven mi creatividad a un "estado normal" ;-)

Hoy voy a hablar del diseño web adaptable (RWD -Responsive Web Design- son sus siglas en inglés), que dicho en román paladino y resumiendo mucho, es hacer que nuestra página se vea en cualquier dispositivo (ordenador, tablet, smartphone, ....).
Para ello, haremos que nuestro contenido se redimensione y se coloque según las necesidades. Es decir, el contenido fluye utilizando media queries de CSS3.

Esto implica la necesidad de pararse a pensar un poco (bastante) el diseño antes de empezar a picar código, pero tiene la gran ventaja de que el mismo desarrollo sirve para cualquier dispositivo con la consiguiente ganancia en mantenibilidad de nuestro sitio y visibilidad de nuestros contenidos.

Es importante tener en cuenta eso de "el contenido fluye", que el contenido se coloque.

En el siguiente ejemplo, vemos que el contenido se redimensiona:



@{ Layout = null; }
<!DOCTYPE html>
<html>
<head>
<meta name="viewport" content="width=device-width" />
<title>pruebasinRWD</title>
</head>
<body>
<div style="width:48%; background-color:aqua; float:left">
Lorem ipsum dolor sit amet, consectetuer adipiscing elit..
</div>
<div style="width:48%; float:left">
Li Europan lingues es membres del sam familie...
</div>
</body>
</html>

El resultado que obtenemos es:



Y si redimensionamos la pantalla




Vemos que el contenido se ha redimensionado correctamente, pero quizás debería haberse recolocado de otra manera para hacer la página más visible en cualquier dispositivo como vemos a continuación











Perdón

Lo primero quería pedir perdón a mis lectores por el tiempo que he estado sin publicar nada. Falta de tiempo y problemas con el ordenador me han puesto difícil escribir. También quería pediros perdón porque voy a cambiar un poco la estructura que tenía pensada inicialmente para el blog. Voy a hacer posts independientes hablando sobre temáticas más variadas. Voy a reemprender mi andadura por estos lares haciendo una reflexión sobre algo que me ha pasado esta semana. Actualmente trabajo para el departamento de desarrollo de una empresa de formación online. En una de las reuniones semanales para ver el estado de los proyectos, el jefe de proyecto lanzó una frase: - "Hay que desarrollar un módulo nuevo. Lo vamos a hacer con .NET Core y Bootstrap" - "¿Y porqué .NET Core?", le pregunté yo - "Porque es lo último", respondió. "Además es muy fácil" me dijo enseñándome link a un tutorial. - "Bueno, ¿pero es lo que necesitamos?. ¿Hay personal con la suficiente formación en el departamento para abordarlo?", le repliqué. - "Víctor eres un miedica (realmente empleó otra expresión que no prefiero no poner aquí). ¿Ves? Abres Visual Studio, clickas en proyecto nuevo, ..... y sigues el tutorial". - "Y con Bootstrap, lo mismo", me dijo abriendo la página principal de Boostrap. "¿Ves? Si tienes los estilos ya definidos". - "Bueno, pero hacer diseño responsive, es algo más que poner un enlace a Boostrap", le dije ya un poco molesto. - "Anda, anda, que eres un miedica...", terminó diciendo de nuevo. Que esta conversación hubiera sido con una persona que no desarrolla software, me hubiera parecido normal; pero con el jefe de proyecto me pareció preocupante. Desarrollar software es más que abrir Visual Studio (o el IDE que se use en cada caso) y empezar a picar código, copiando de aquí y de allí. Primero creo que hay que entender que tipos de arquitectura hay, que ofrece cada tecnología, ... para saber cuándo aplicar una u otra. No siempre DDD es la mejor solución, ni hacer una aplicación Web aplica en todos los casos, ni una base de datos relacional es la mejor solución siempre. Tampoco creo que la solución pase por reuniones interminables filosofando sobre arquitecturas o si TypeScript es mejor que .... o peor que ... y al final se hace una aplicación complicada de desarrollar y mantener. Creo que hay que pensar en hacer las cosas simples y fáciles de entender y mantener. Hay que ser consciente de la gente que tenemos en el equipo, de los tiempos de entrega que tenemos y de las aplicaciones que desarrollamos. ¿O no? ¿Seré de verdad un miedica?