Mostrando entradas con la etiqueta html. Mostrar todas las entradas
Mostrando entradas con la etiqueta html. Mostrar todas las entradas

lunes, 15 de agosto de 2016

Si programas tienes que usar una guia de estilos para tu codigo...

Si actualmente estas programando y no estas usando una guía de estilo para tu código de acuerdo al lenguaje que usas,  estas cometiendo un gran error...

Una guía de estilo de código en palabras simples es como tu código luce , como lo ven los demás. Si miras todo el código que has escrito hasta ahora podrás notar un cierto patrón, ese es tu propio estilo.
El problema con esto es que no es entandar y la mayoría de las veces solo tu podrás entenderlo.

No serial genial que todos escribieran el código como tu lo haces ?  .... Por esa razón mi buen amigo es que existen las guía de estilo de código, para que todos podamos leer y entender el código de los demás.

Una guía de estilo de código por lo general tiene lo siguiente:

  • Como y cuando usar comentarios
  • Como usar y cuanto espacio e indentación deberías de utilizar
  • Nombres adecuados para tus variables y funciones
  • Como agrupar tu código
  • Que técnicas usar o cuales no, dependiendo del lenguaje
Si tu objetivo es trabajar en una gran empresa, necesitas aprender los estilos de código para cada lenguaje que usas. Es un gran dolor de cabeza cuando un nuevo programador quiere escribir código a como le da la gana, Si tu eres uno de estos seguramente no vas a durar mucho.

Una rápida búsqueda en Google puede ayudarte a encontrar los estilos que buscas, pero a continuación podre algunos





sábado, 23 de julio de 2016

Guia para iniciar en flex-box con CSS 3


propiedades flex-box
descripción de las propiedades flex-box

Flex-box es la nueva técnica de maquetación CSS 3, con la cual es mucho más fácil crear estructuras HTML sin tener que usar float, inline-block o los muchos trucos que usábamos antes. 2015 es el momento indicado para aprender usar flex-box ya que ha alcanzado un buen soporte en navegadores. Puedes consultarlo en caniuse.com.

La primera idea que tuvimos en codingonweb fue hacer un buen tutorial sobre como usar flex-box, pero en el proceso de conseguir información me encontré de que ya existen muy buenos tutoriales para aprender desde cero. Con este artículo solo quiero aclarar ciertas cosas que considero no son explicadas claramente, asi pueden usar este articulo como complemento para los tutoriales.

El primero paso es leer los excelentes tutoriales de flex-box que he encontrado:
Ahora si no quedastes claro y necesitas una refuerzo lee el resto del articulo, aunque si le entendiste a la primera no sera necesario.

Flexbox ofrece una manera eficiente de maquetar cubriendo espacios disponibles ya sea expandiendo o encogiendo a sus elementos hijos. Para usar flex-box solo tienes que usar en un contenedor la propiedad display: flex. Esto convierte al elemento en un contenedor flex-box y automáticamente todos los elementos hijos directos se consideran elementos flexbox.

Aquí tienes un ejemplo sencillo para ver mejor en acción flex-box. Le he puesto una altura al contenedor para una mejor comprensión.

Ahora lo interesante aquí es que con este ejemplo no podemos ver en acción lo de : “cubriendo espacios disponibles ya sea expandiendo o encogiendo a sus elementos hijos”. Para esto solo tienes que agregar ancho a los elementos hijos, no importa si es en píxeles ó porcentajes. Lo interesante es que si el ancho de los hijos excede el ancho de su contenedor, flex-box fuerza a sus hijos a encogerse, logrando el comportamiento de caja flexible. Ejemplo (redimensiona la zona de resultado)

Como puedes ver flexbox nos crea unas cajas flexibles que se adaptan automáticamente.
La propiedad “justify-content” sirve para determinar cómo queremos alinear los elementos flexbox(hijos) dentro de su contenedor en el eje horizontal. Ojo que para poder ver en acción esta propiedad la suma de los anchos de los hijos no tiene que exceder el 100% de su padre, tienes que dejar un espacio para poder ver como flex-box alinea los elementos, Ejemplo

Ahora por defecto flex-box toma todos los hijos y los encoge ó expande para que siempre estén dentro de su contenedor no importa si la suma de sus anchos exceden el 100% del ancho de su padre ó hay elementos adicionales, ejemplo:

Como puedes ver en el ejemplo anterior los hijos tienen 25% de ancho y son 7, por lo que 25*7 = 175%, sobrepasa totalmente el 100% del padre pero flex-box los mantiene dentro de su contenedor. Este comportamiento es por defecto, pero podemos cambiarlo con la propiedad “flex-wrap”. Ejemplo:

En el ejemplo anterior podemos ver que cambiando el valor de esta propiedad podemos hacer que los elementos que no caben en el contenedor sean desplazados hacia abajo. Hay que poner mucha atención en que cada elemento ocupa 25% entonces solo 4 de ellos alcanzan en su contenedor padre para lograr el 100% los demás sobrantes serán desplazados, La propiedad “align-items” es usada para alinear los elementos flex-box (hijos) en el eje vertical. Ejemplo:

En el ejemplo he alineado los elemento hacia abajo en el eje vertical. También podemos hacerlo en el centro:

Las propiedades anteriores son solo algunas de las mas comunes y que se usan solamente en el contenedor flexbox. Pero los hijos también tienen propiedades que podemos usar para manipularlos individualmente como son:

Order: Se usa para alterar el orden de los elementos, independientemente del orden en el HTML. Por defecto todos los elementos flex-box tiene 0. Si queremos pasar un elemento de primero sobre todos los demas usamos -1. Ejemplo:

La parte interesante aquí es que el orden va de menor a mayor, como -1 es menor que cero , este elemento ira de primero. Ahora nos toca hablar de 2 propiedades que son muy poco utilizadas pero que tienden a la confusión, estas propiedades son usadas solo en elementos flex-box(hijos):

flex-grow: Determina cuanto un elemento va crecer con respecto a los otros hijos dentro del mismo contenedor, si hay espacio disponible para hacerlo. Ejemplo:

Ojo esto es muy importante : “si hay espacio disponible para hacerlo”, lo que quiero decir, es que si entre todos los hijos logran el 100% de ancho del padre no habrá espacio para ser usado por la propiedad flex-grow. Ejemplo:

Como puedes ver en el ejemplo anterior los hijos ahora tienen 15% , lo cual hacen 75% entre todos. El resto del espacio disponible lo toma el elemento con flex-grow.

flex-shrink: Es el inverso del flex-grow, determina cuanto un elemento se va encoger con respecto a los otros hijos dentro del mismo contenedor. Para ver esto en acción los demás hijos tienen que aumentar su tamaño para forzar que se encoja. Para comprender mejor este comportamiento haz lo siguiente con el siguiente ejemplo:

En el ejemplo anterior el tercer div tiene la clase “shrink”, ahora aumenta el tamaño de los elementos con la clase “container_item” de 25% a 40% y haz click en play. Solo se encoge cuando la suma del ancho de todos los hijos supera el 100% de contenedor.

flex-basis: define un tamaño base para un elemento, lo demas elementos se van a comportar en base a este. Es muy util para hacer algo como esto Ejemplo:

Flex-box viene a solucionar muchos problemas de maquetacion que teniamos y aprender a usarlo te quitara muchos dolores de cabeza. Par terminar te recomiendo los siguientes link para completar tu aprendizaje:




¿ Que es una página web 404 ?

404 wikipedia

Imaginemos que tenemos un sitio web con la siguiente estructura:
  • index.html
  • blog.html
  • productos.html
  • contacto.html
Cuando nuestros visitantes entran a nuestro sitio atraves de una url por ejemplo: www.minegocio.com , el archivo que se carga por defecto es el index.html. Despues nuestros usuarios navegan por el sitio web por medio de links que los conducen a cada una de las secciones. Por ejemplo:
  • www.minegocio.com/blog.html
  • www.minegocio.com/productos.html
  • www.minegocio.com/contacto.html
Aqui todo bien. Pero que pasa, cuando un link no apunta al archivo correcto ó cuando el archivo ya no existe ó el usuario escribio mal la direccion. En todos estos casos seguramente los visitantes verán una página 404 algo similar a esta, dependiendo del navegador que usen:

404 page no found

Esta pagina solo les dice a los usuarios que la página o contenido que estaba buscando no fue encontrado. El usuario menos experimentado en este momento no sabe que paso o que hacer, lo cual es frustrante. No sería una mejor idea que cuando esto pasara, le indicaramos al usuario un poco más de información sobre lo que ha pasado y tal vez alguna sugerencia para tratar de resolver el problema. 

De esta manera podemos guiar a nuestros visitantes de una manera correcta hacia donde podría encontrarse la información. Para esto es que existen las páginas 404. Si creas un archivo y le pones de nombre “404.html”, esa página siempre será cargada cada vez que los visitantes intenten acceder a un contenido que no existe o que los link estan incorrectos.

Dentro de este archivo podemos incluir toda la información necesaria de por que ocurrió ese error e información útil para guiarlo hacia otro contenido que podria interesarle
En internet existen sitios donde puedes descargar páginas 404, para incluirla en tu pagina web solo basta con buscar y descargar.

Si quieres crear tu mismo tu página 404 puedes obtener inspiración en google buscando por el término por ejemplo: “best 404 page”. Un sitio que tiene un buen top de esta pagina es :


Otra idea muy útil es incluir un formulario de búsqueda en estas paginas para darle al usuario una opción de buscar en sitio web. Si quieres saber como lograr esto necesitas saber un poco de javascript y el uso de las API de Google. Para una guia paso a paso puedes visitar este web:


Aunque una pagina sencilla y con información descriptiva puede bastar para sitios sencillos.





miércoles, 25 de mayo de 2016

Que es SVG y como usarlo en paginas web

SVG es un formato de imagen para dibujos vectoriales, el mismo tipos de archivos que usan los diseñadores gráficos con Adobe Illustrador.  Gracias a los nuevos estandares web podemos usar este tipo de formatos de imagen y aprovechar todos los beneficios.

Beneficios

  • Tamaño de archivo muy pequeño y comprimido
  • La image se puede ver perfectamente en cualquier resolución de pantalla ya que puede ser escalado sin problemas, pudiendo verse perfecto en resoluciones retina display.
  • Tamaño del archivo reducido.


Normalmente ese tipo de archivos son creados con alguna herramienta de dibujos vectoriales como Adobe Illustrador. Ahora mismo existen muchos editores online de SVG donde puedes crearlos y editarlos.

Independientemente de la herramientas uses, tu puedes usar un SVG de 2 maneras:


  1. Con un archivo físico con la extensión .svg
  2. O con el codigo SVG que es similar a este:
Con cualquiera de los 2 puedes trabajar.  Para usar el SVG solo tienes que usar la etiqueta img como con cualquier imagen normal y con CSS puedes controlar el tamaño. Ejemplo:


Tambien puedes usar un SVG como fondo de un elemento con CSS.

.container {
    width: 100px;
    height: 82px;
    background: url(yourFile.svg);
}

También otra opciones es usar la etiqueta “object”. Ejemplo:


<object type="image/svg+xml" data="namefile.svg">Your browser does not support SVGs</object>

Usando el código SVG


Descarga el Siguiente archivo:


Después abre el archivo con tu editor de texto, por ejemplo yo estoy usando sublime text, cuando abras el archivo verás el código SVG que crea la imagen. Este código lo puedes copiar y pegar directamente en un archivo HTML y verás como el SVG aparece, El navegador lo cargara automáticamente.

Los archivos SVG pueden ser optimizados ya que como puedes ver en el código del archivo del “Che.svg” hay muchas etiquetas adicionales. Puedes usar la siguiente herramienta para esto.


También puedes dar estilo individualmente a cada elemento del SVG, tan solo tienes que asignar clases para poder dar tus estilos. Ten en cuenta que para dar estilo a los SVG tienes que usar propiedades CSS especiales para ellos, los cuales tienes que buscar en google por ejemplo.



Si quieres conocer un poco más en detalle cada elemento dentro del SVG tag , te sugiero que visites este link:



Adicionalmente esta tabla te ayudará a entender lo que puedes hacer con los SVG dependiendo la manera en como lo insertes en tu página web.



Lo que puedes hacer
Object
Inline
Img
Background-image
CSS Manipulation
Yes
Yes
Some inline
Some inline
JS Manipulation
Yes
Yes
No
No
SVG Animation
Yes
Yes
Yes
Yes
Interactive SVG Animation
Yes
Yes
No
No

Usando Javascript con SVG


También podemos manipular los SVG con javascript como lo haríamos con un objeto normal HTML, podemos usar javascript puro o jquery para esto. En el siguiente ejemplo que encontre internet puedes ver cómo se selecciona el elemento y después se cambia su propiedad “fill”.



Si quieres una manipulación más avanzada con los SVG te recomienzo las siguientes librarias:



Habiendo escrito todo lo anterior, Deberías de ir considerando de usar svg en todos tus iconos y logos de tus proyectos web. Si por alguna razon aun no estas convencido visita este link :

http://talks.brennaobrien.com/svg/#/


links






domingo, 20 de diciembre de 2015

Quiero aprender a programar pero.., ¿ Que lenguaje de programacion aprendo ? 2015

Si quieres entrar en el mundo de la programación, seguro habrás hecho una pequeña búsqueda en Google sobre ¿ como aprender a programar ? ó tutoriales de programacion .

Te habrás dado cuenta que hay montón de lenguajes de programacion para aprender, y solo piensas : ¿ cual elijo ? . Con el siguiente articulo quiero darte una guía rápida por donde podrías empezar según mi experiencia personal, pero todo depende de ti y tus gustos sobre lo que quieres hacer en el futuro.

Primero tienes que descubrir que quieres hacer:

¿ Quieres crear paginas web ?
¿ Quieres aprender a crear aplicaciones web ?
¿ Quieres crear aplicaciones para móviles ?


Saber las respuesta a estas preguntas te dará la orientación inicial por donde comenzar. Recomiendo que leas los siguientes artículos para ayudarte a encontrar una repuesta a esas preguntas

Otra sugerencia que puedes hacer es investigar las tendencias en lenguajes de programacion en google.


Ya como ultima recurso puedes consultar cuales son los cursos mas populares en sitios de educación en linea, con una búsqueda rápida en google puedes ver múltiples opciones. A nivel personal solo conozco estos:

Lo gracioso que he notado de algunos de estos sitios es que promocionan cada lenguaje como lo ultimo y tienes que aprenderlo si no quedaras fuera, dejando al novato con la idea de que tiene que aprender todo sin idea de donde comenzar. Realmente no hay que culparlos ellos tienen que vender sus cursos.

Hasta este punto espero que ya tengas una buena idea de que lenguajes quieres aprender pero si aun estas perdido te dejare una lista con los lenguajes que yo creo debes aprender a manera muy personal según mi experiencia.

Sigue esta lista en el orden numérico.

  1. HTML
  2. CSS
  3. Javascript puro
    1. jQuery
  4. Javascript Frameworks
    1. AngularJs 2
  5. Chrome DevTools (para encontrar error en tus aplicaciones)

Unas vez que aprendas estos lenguajes tienen 2 opciones  PHP ó NodeJs cualquiera que escojas es una excelente opción no importa que te digan o leas en Internet.

  1. PHP puro
    1.  Laravel framework
ó
  1. Node puro
    1. Express Js
Se que la lista es extensa y cuando revises la documentacion de cada lenguaje sera aun mas larga, pero no te desanimes si día tras días le dedicas una hora podrás lograrlo. 

Consejos.
  1.  No intentes aprender todo sobre un lenguaje, aprende solamente lo básico y pasa al siguiente lenguaje con el tiempo sabrás buscar solo lo que necesitas.
  2. Crea proyectos de ejemplos, si tratas de aprender solo por hacerlo nunca avanzaras y te aburrirás con el tiempo. Piensa en alguna idea genial o proyecto que quisieras crear y con eso en mente practica y crea tus ejemplos.
  3. Se parte de una comunidad, Eso te ayudara a darte inspiración y fuerza para seguir, conocer gente nueva e interesante con tu misma visión. 
    1. Platzi y Codigo facilito son comunidades excelente a la cual puedes unirte.









sábado, 19 de diciembre de 2015

Maneras de como desarrollar aplicaciones móviles

En el mundo de las aplicaciones móviles tenemos muchas herramientas a nuestra disposición para crear nuestras app. Pero fácilmente podemos dividirlas en :
  1. App nativas: IOS , Android, Window , Firefox, etc.
  2. App hibridas: HTML5, Appcelerator, PhoneGap , etc.
  3. Web apps: HTML5, javascript, CSS, php, nodejs, Ruby, etc.
Conociendo un poco de cada una de ellas nos ayudara a entender cual es el adecuado para nuestro próximo proyecto móvil.

App nativas


Una aplicación nativa es una aplicación para smartphone que es programada con un lenguaje de programación específico para la plataforma del teléfono. Por ejemplo
  •     Swift para IOS
  •     Java para android
  •     C# para windows phone

La ventaja de programar una app de este tipo:
  •     Tienen un alto rendimiento , son rápidas y muy confiables, cuando digo confiables hablo de que siempre van a correr de la misma manera en todos los dispositivos para el cual fue creado, los elementos UI son consistentes.
  •     Tienes acceso a todas las características del dispositivo como: cámara, libreta de contactos, acelerómetro, gps, etc.
  •     Estas app pueden ser usadas sin conexión a internet, la mayoría de los juegos son de este tipo.
  •     Mejor distribucion por que disponen de un marketplace donde los usuarios pueden descargar tu app.
  •     Los programadores tienen disponibles todas las herramientas y documentación necesaria (SDK)

Desventajas :

  •  Son muy costosas en términos de desarrollo porque están limitadas a la plataforma en la cual fue creada, esto aplica solamente si el desarrollador quiere que su aplicación este disponible en la mayoría de dispositivos móviles del mercado. Teniendo que portar la aplicación para cada plataforma.
  •  El proceso de aprobación de parte del marketplace puede ser tedioso, por que la aplicación tiene que reunir ciertos estándares para ser publicada.
  • El marketplace toma un porcentaje por cada venta de tu aplicación.

App hibridas


Al igual que las app nativas, las app híbridas corren en el dispositivo móvil, pero son programadas usando tecnologías web estándar como HTML5, CSS y Javascript.

Phonegap es muy popular y es usado para empaquetar este tipo aplicaciones. Toma todo el html, css, javascript y lo empaqueta para ser distribuido en cualquier plataforma móvil.

El resultado es una aplicacion que puede ser instalada en la plataforma en la cual fue escogida previamente durante el proceso de exportación. Esta aplicaciones corren dentro de un contenedor nativo y deja que el motor del navegador (webview) cargue el HTMLy el javascript de manera local.

Lo importante de este tipo de aplicaciones es la capa de abstracción que nos permite acceder a las APIs usando javascript, por ejemplo características del dispositivo que no pueden ser accedidas por medio de una web app como , acelerometro, cámara, local storage , etc.


Ventajas

  •     Tienes acceso a las características del dispositivo como: cámara, libreta de contactos, acelerómetro, gps, etc.
  •     Pueden ser programadas usando tecnologías web estándar
  •     El mantenimiento y los tiempos de desarrollo son bajos
  •     Pueden ser publicadas en los marketplace
  •     Exportación a múltiples plataformas
  •     Pueden ser usadas sin conexion a internet

Desventajas

  •     No tienen un alto rendimiento.
  •     Los elementos UI puede no ser consistentes en todo los dispositivos y requiere un trabajo extra para lograrlo.
  •     Debido que usan tecnologías web, los programadores traen consigo muchas malas prácticas en el desarrollo.



Web apps


Si estas comenzando con el mundo de desarrollo movil y ya sabes sobre web, esta es tu opción. Ya que solo necesitas saber las tecnologías web estándares HTML 5, CSS3 y javascript y algún lenguaje del lado del servidor como PHP, Nodejs, ruby, etc. para guardar y acceder a los datos.

Una web apps es un conjunto de páginas web diseñas para que su contenido sea consumido desde dispositivos móviles. Por ejemplo usando técnicas como responsive design.

Ventajas

    Fácil desarrollo y mantenimiento.
  •  Usan tecnologías web estándar.
  •  No necesitan aprobación del marketplace, pueden ser accedidas directamente.
  •  Es independiente de la plataforma ya que solo necesitan un navegador web.
  •  Los usuarios no requieren bajar actualizaciones
  •  Bajo coste para el desarrollo ya que usa tecnologías libres y estándares web.
  •  Hay muchos frameworks que puede acelerar el tiempo de desarrollo. (jquery mobile, sencha touch, etc)
Desventajas
  •     No pueden acceder a las características del dispositivo como: cámara, libreta de contactos, acelerómetro, gps, etc.
  •     Debido a que usan el navegador de los usuarios los elementos UI y rendimiento no es consistente en todos los dispositivos ya que estan limitados al hardware del movil.
  •     La calidad no está garantizada por nadie.
  •     Hay que soportar muchos navegadores para que la app sea consistente y requiere un gran esfuerzo.
  •     Necesitan una conexion a internet para ser usadas

¿ Cual escoger ? Bueno como siempre todo proyecto tiene sus necesidades únicas pero las siguientes preguntas te pueden servir de guía para tu decisión.
  •     ¿ Cuan importante será la velocidad y rendimiento de tu app ?
  •     ¿ La aplicacion tiene que tener acceso a las caracteristicas del dispositivo? (cámara, acelerometro, etc)
  •     ¿ Tu aplicacion funciona con acceso a internet ?
  •     ¿ Tu aplicacion necesita soportar múltiples dispositivos ?
  •     ¿ Tengo el presupuesto y tiempo para aprender nuevos lenguajes de programación ?
  •     ¿ Quieres vender tu aplicación en un marketplace ?

Para Terminar les dejo esta infografia por : http://www.skilledup.com


 

sábado, 4 de octubre de 2014

Javascript domina la web... pero hay que tener un poco de cuidado





Lo siguiente son trozos de varios artículos que he leído con los que estoy de acuerdo y creí que vale pena compartir en manera de un unico post.

 Quiero comenzar diciendo que soy un gran fan de javascript, escribo gran cantidad de código con el y lo encuentro increíblemente útil, de ambas maneras como un lenguaje de programación y como una manera de mejorar la usabilidad y accesibilidad del contenido web. En los primeros días de la web muchos programadores se distanciaban mucho de javascript, muchos lo miraban como un lenguaje de juguete y lo sentían similar a html y css. No era tan poderoso como Java,C o Perl por lo que no valia la pena aprenderlo. Pero con el pasar de los años javascript cambio mucho.

 La mayoría de los programadores comenzaron a tomarse enserio javascript cuando AJAX se volvió popular y con el nacimiento de los frameworks MVC javascript (angular,ember,ect) muchos programadores empezaron a volcarse a javascript. El único problema que veo con esto es la desconexión fundamental de estos programadores parecen tener en la manera en que ellos crean código para la web. En el desarrollo tradicional de software tenemos cierto control sobre nuestro entorno, pero en la web no.

 Por ejemplo si estamos escribiendo un programa del lado del servidor en Python, Rails o php una de estas cosas es cierta:

 1 - Nosotros controlamos el entorno del servidor: SO , versión de lenguaje paquetes , ect
 2 - Nosotros no controlamos el entorno del servidor: Pero tenemos conocimiento de el y podemos crear código deacuerdo a sus especificaciones y todo estara bien.

 En el mundo tradicional de instalación de programas nosotros podemos controlar nuestro entorno poniendo ciertas restricciones en los SO para que nuestro código pueda correr ,ram , espacio en disco duro etc. Nosotros establecemos todo esos requerimientos para que los que usuarios puedan usar nuestros programas.

 En la web sin embargo todo esto es incierto. No tenemos control del entorno  en donde nuestro código javascript,html,css se ejecutaran. Nuestros usuarios controlan el aparato que usan, nuestros usuarios deciden que sistema operativo usar, cuanta ram  y espacio en disco quieren , la velocidad del procesador y el tipo de navegador que quieren usar. Y los proveedores de Internet se sientan en medio de nosotros y nuestros usuarios controlando la velocidad de la red , latencia y por ultimo que contenido permiten que el usuario descargue.

Lo unico que podemos hacer es tratar de hacer la experiencia adaptable a cualquier tipo de situación y cruzar los dedos para que todo salga bien. El problema fundamental de confiar en javascript  es que crea la ilusión de que estamos en control, seguramente si construimos una aplicación de uso personal o para algún familiar nosotros podemos decidir los requisitos para nuestra app SO/navegador/ram/etc  pero eso no es una realidad para el mundo web.

No podemos confiar ciegamente en la disponibilidad de una versión de SO ó versión de navegador cuando se trata de llevar nuestra app a internet, en lugar debemos construir experiencias que sean adaptables y tomar decisiones inteligentes  sobre las tecnologías especificas a usar en orden de tomar ventajas de sus beneficios mientras somos conscientes que no podemos garantizar la completa compatibilidad en este caso entra en juego algo llamado "progressive enhancement"

El concepto de "progressive enhancement" se ha convertido en unos de los temas de mas debate en la web de la actualidad, para ponerlo simple "progressive enhancement" es la técnica para construir sitios web con fuertes cimientos para que se a accesible a un amplio rango de situaciones (SO , navegadores, ram, ect)

Si tienes tiempo puedes leerte este post de como twitter uso esa técnica en el 2012 link.

He tomado una tabla de unas pruebas hechas por Jake Archibald en su blog donde ha hecho pruebas de parseo y ejecución de jquery 2.1.1 en diferentes dispositivos.


Parse and execution times of minimized jQuery 2.1.1
Device Browser Median Parse Median Execution Median Total
Blackberry 9650 Default, BB6 171ms 554ms 725ms
UMX U670C Android 2.3.6 Browser 168ms 484ms 652ms
Galaxy S3 Chrome 32 39ms 297ms 336ms
Galaxy S3 UC 8.6 45ms 215ms 260ms
Galaxy S3 Dolphin 10 2ms 222ms 224ms
Kindle Touch Kindle 3.0+ 63ms 132ms 195ms
Geeksphone Peak Firefox 25 51ms 109ms 160ms
Kindle Fire Silk 3.17 16ms 139ms 155ms
Lumia 520 IE10 97ms 56ms 153ms
Nexus 4 Chrome 36 13ms 122ms 135ms
Galaxy S3 Android 4.1.1 Browser 3ms 125ms 128ms
Kindle Paperwhite Kindle 3.0+ 43ms 71ms 114ms
Lumia 920 IE10 70ms 37ms 107ms
Droid X Android 2.3.4 Browser 6ms 96ms 102ms
Nexus 5 Chrome 37 11ms 81ms 92ms
iPod Touch iOS 6 26ms 37ms 63ms
Nexus 5 Firefox 32 20ms 41ms 61ms
Asus X202E IE10 31ms 14ms 45ms
iPad Mini iOS6 16ms 30ms 46ms
Macbook Air (2014) Chrome 37 5ms 29ms 34ms
Macbook Air (2014) Opera 9.8 14ms 5ms 19ms
iPhone 5s iOS 7 2ms 16ms 18ms
Macbook Air (2014) Firefox 31 4ms 10ms 14ms
iPad (4th Gen) iOS 7 1ms 13ms 14ms
iPhone 5s Chrome 37 2ms 8ms 10ms
Macbook Air (2014) Safari 7 1ms 4ms 5ms


Lo que  Jake Archibald dice :  "La horrible verdad sobre javascript cuando se trata de dispositivos que no son muy poderosos en hardware. Puedes pensar que esos modelos donde los tiempos son mas grandes son modelos viejos que nadie usa, lo cual es un error por que según las estadísticas las personas usan mas dispositivos antiguos que nuevos. También no importa que navegador usen lo mas importante es el poder de hardware del dispositivo.

Lo interesante de los tiempos de parseo y ejecución es que son para la ultima versión de jquery la cual pesa 88kb minificada, sin plugins adicionales sin frameworks. De acuerdo con los últimos reportes de HTTP archive, la media de transferencia de archivos JS son de 230kb". Las pruebas que el hizo son solo una fracción de ese tamaño. Jake Archibald dice que no pidio que jquery hiciera nada.

Por eso en algunas ocasiones debemos considerar reducir la dependencia de javascript en nuestros proyectos, no solo es saludable en tiempo de carga sino sera accesible para las personas que tienen javascript desabilitado en sus navegadores.

Como programador de javascript yo uso el framework angularJS y me parece impensable que algún usuario tengo desabilitado javascript en su navegador, pero aunque no queramos admitirlo existen y las app que usan frameworks javascript se vuelven cada vez mas pesadas. Las recomendaciones que siempre leo en internet son:


  • Reducir lo maximo posible javascript
  • Usar mas los render del lado del servidor
  • modular tus archivos javascript y usar lazy loading
  • Algunos recomiendan que la pagina principal que tiene datos para presentar sean cargador por el lado del servidor primero y después usar ajax para lo demas, algo asi como incluir un json con todos los datos necesarios iniciales en el html.


Como Nate Koechley’s dijo una vez:

"En un empleo anterior a yahoo, siempre me hacian la pregunta al inicio del cualquier projecto: ¿ Cuales navegadores debemos soportar en este projecto ? vamos a soportar netscape 4 ? IE 5? y siempre me fue preguntada en un sentido binario donde la respuesta siempre tenia que ser si o no. y con el tiempo nos dimos cuenta que el principal objetivo de nosotros era la maxima disponibilidad posible. Y esa fue la primera cosa que tuvimos que entender, el soporte no es binario. La segunda cosa que tuvimos que aprender es que soportado no significa realmente identico. En lugar de soportar un navegador, nosotros queremos dar al navegador lo que puede manejar de la manera mas eficiente posible."


Hace algún tiempo salio una web con el titulo “You Might Not Need jQuery”  el sitio en si ofrece ejemplos de código donde puedes hacer lo mismo que jquery pero con javascript nativo por nosotros mismo.

Lo interesante de esta web son el sinnúmero de comentarios que recibio con opiniones divididas sobre el tema. Lo cual hace preguntarse si una simple sugerencia sobre no usar una tecnologia determinada puede generar tanta discusion sobre el tema entonces debemos preguntarnos si estamos demasiado  dependientes de ella.

No estoy diciendo que no debamos usar frameworks y librerías, De hecho me gusta mucho jquery y los frameworks javascript pero lo que preocupa es que estas librerias se han convertido en librerías por defecto en cualquier proyecto y damos por hecho que esa dependencia es sana y la mayoría dela gente esta amarrada a esa tecnologia. Esto obviamente lleva a que tengamos librerías con un peso considerable en nuestros proyectos por considerarlas obligatorias.


http://aaron-gustafson.com/notebook/2014/a-fundamental-disconnect/
http://timkadlec.com/2014/09/js-parse-and-execution-time/
http://jakearchibald.com/2013/progressive-enhancement-is-faster/
http://timkadlec.com/2013/08/being-practical/
http://sixrevisions.com/web-development/progressive-enhancement/







sábado, 21 de junio de 2014

Wireframe, prototype, mockup ¿ Cual es la diferencia en diseño web ?





Las mayoria de las personas piensan que Wireframe, prototype y mockup  son la misma cosa,  con este post quiero mostrar las diferencias entre cada uno de ellos.

¿ Que es un wireframe ?


Es la mas simple representación de un diseño web, piensa en el como la estructura básica de la pagina web. Wireframe deberia de contener la representación de cada pieza importante del producto final.

Cuando decimos "representación" quiere decir que no tenemos que entrar en detalles exactos,  pero debemos crear una solida idea de lo que seria el producto final. Con esto estamos creando un mapa, una idea de como seria el diseño final web.

Crear un wireframe debería de ser una tarea rápida y la mayoría del tiempo debe de emplearse en generar ideas y discutir con el equipo de diseño. Un buen wireframe comunica la idea general a tu equipo de trabajo de que camino se esta tomando en el diseño.

Algunos ejemplos de wireframe :





Los wireframe son estáticos y sin ninguna interacción , por lo que deberían siempre de ser presentados en conjunto con documentacion adicional sobre su propósito. Existen muchas herramientas gratuitas para crear wireframes , una de ellas es : https://wireframe.cc/


¿ Que es un prototype ?


Prototype a veces es confundido con un wireframe, pero un prototype es una representación media del diseño que simula la interacción del usuario con la interfaz y el contenido del producto final. Principalmente permite testear como el usuario interactua con la interfaz de una manera similar al producto final, por lo que Prototype tiene que tener interacciones y enlaces que funcionen, pero su contenido sigue siendo estático. Un prototype es una simulacion final de la interaccion entre el usuario y la interfaz de calidad media  del producto final.

Puede no lucir exactamente igual al producto final pero lo suficientemente similar para demostrar la interacción del usuario. Esto nos demuestra que prototype se usa principalmente para pruebas completas de interfaz, antes de que la programación final del producto comience.

Hay que tener cuidado en usar un prototype por que para crear las interacciones de la interfaz habria que  trabajar con el html , css  y Javascript para crearlas. Aunque existen herramientas de pago que permiten crearlas por ti, como por ejemplo : http://proto.io/.  En el siguiente vídeo pueden ver como agregan interacción a un prototype de una App móvil.



Resumen : "Prototipo: Representación navegable del producto final web. De calidad media"

¿ Ques un mockup  ?


Mock-up: Representación estática de un producto web en calidad alta.

Con el podemos vender  la idea final de nuestro producto e  instar a nuestros clientes a darnos feedback sobre el diseño, es lo mas cercano al diseño final que podemos mostrar a nuestros clientes. La diferencia con  protoype es que un mockup no necesariamente tiene que tener html programado, pueden ser imágenes del diseño final, mientras que prototype si.Y un mockup generalemente no tiene interactividad

Para terminar les dejo un vídeo de mejorando.la donde explican la diferencia de cada uno.




Para terminar he encontrado una App muy util para hacer rapidos prototipos con solo dibujos en papel, visita el siguiente link : https://popapp.in/

Y si quieres un poco de inspiración para hacer tus prototipos puede visitar esta comunidad: https://spaces.proto.io/

Algunos libros gratuitos sobre diseño de prototype y mockup:



link : http://designmodo.com/wireframing-prototyping-mockuping/



 http://saulburgos.com/books/googlemaps.html




viernes, 23 de mayo de 2014

Responsive design con medidas relativas (em y rem ), no mas pixeles.




En la actualidad cuando hablamos de responsive design hablamos de que nuestras web app se adapten a cualquier resolución de pantalla, ya que la gran cantidad de dispositivos móviles y tamaños de pantalla es increible. Una manera de lograr esto es con “Media Queries” por medio de ellas se trata de “identificar” el comportamiento del layout de acuerdo a las resoluciones de las pantallas más usadas.

Normalmente se crean “breakpoint”, los breakpoint son los tamaños específicos donde tu diseño se rompe y es en ese momento donde tenemos que escribir  “Media Queries” para resolver el problema.

Creo que alguien definió el proceso de esta manera : “Comienza con la pantalla más pequeña, luego expándela hasta que luzca como la mi*rda. Tiempo de hacer un breakpoint!"

Hoy en dia esta manera de pensar en el diseño no es lo adecuado ya que la web no es solamente  fluída, ya no hay más “pixel perfect” y debemos dejar de pensar que “Media Queries” sirve para setear solamente los anchos de los elementos, debemos de pensar también en los márgenes y  estilos.

Como programadores frontends debemos saber qué cosas podemos controlar y que cosas no. Nuestros usuarios serán los que decidan cómo visualizar nuestro sitio de la manera en la que ellos quieran. Asi que debemos dejar de pensar en “píxel perfect” cuando diseñamos para Web, y saber que los diseños estarán en constante cambio, por lo cual debemos de optimizar el contenido.

Lo primero que tenemos que hacer es configurar correctamente el viewport, normalmente lo configuracion del viewport se hace de la siguiente manera : 

<meta name="viewport" content="width=device-width, user-scalable=no">
ó
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1">

El propiedad width controla el tamaño del viewport , puede tomar valores fijos como 500px  o como en ese caso el valor “device-width” el cual es el ancho de la pantalla del dispositivo en pixeles a una escala de 100%. Instruye a la pagina a que su ancho tiene que coincidir con el ancho del dispositivo.
La propiedad “user-scalable=no" deshabilita las capacidad de hacer zoom y el usuario solo podrá hacer scroll, lo cual da la sensación de que tu sitio parezca una app nativa.

La propiedad “initial-scale” controla el nivel de zoom cuando la página inicia. Algunos navegadores incluidos IOS y Windows phone,mantendrán el ancho de la pagina constante cuando sea rotado en horizontal (landscape mode) ó hagas zoom, en lugar de acomodar el contenido en pantalla. Agregando el atributo "initial-scale=1" instruye al navegador a establecer una relación 1:1 entre los pixeles CSS y los pixeles del dispositivo independientemente de su orientación y permite  tomar ventaja del todo el ancho en modo landscape.

 Pueder ver un ejemplo en este link,section "Responsive Viewport" : https://developers.google.com/speed/docs/insights/ConfigureViewport

“maximum-scale” controla el máximo de zoom permitido al usuario, por lo general siempre lo he visto en valor 1 y esto puede resultar un problema para algunas personas. Aunque los elementos de nuestra web tengan tamaños adecuados puede haber algunos que no se puedan ver correctamente.
Los textos en imágenes podrían verse demasiado pequeños en un móvil. En este caso el usuario tendrá que hacer zoom para leerlo, pero no podrá. Esto supone una frustración para el usuario, algo que tenemos de evitar para ofrecer una buena experiencia.

La manera correcta en que debemos configurar el viewport es esta :

<meta name="viewport" content="width=device-width, initial-scale=1">

Por defecto, "user-scalable" tiene el valor de yes, es decir, el zoom está activado. Si no definen "maximum-scale", el zoom máximo será el determinado por el navegador, lo que resta hacer es tratar de crear nuestras “Media Queries” de manera correcta y adaptar el contenido lo mejor posible.

Cuando en una Web no es especificado el viewport, los navegadores de dispositivos móviles mostraran la web con una resolución de 800px a 1024px, el factor de escala de la página es ajustado para mostrarse, forzando a los usuarios hacer zoom antes de que puedan interactuar con la Web.

Ahora basándonos en que nuestro contenido tiene que adaptarse perfectamente en muchas resoluciones de pantallas, lo correcto sería usar unidades de medidas CSS relativas para los tamaños de letras en lugar de pixeles, por qué necesitamos cambiar los tamaños de letras de acuerdo a los diferentes tamaños de pantalla.

El tamaño de letra que se ve bien en un dispositivo móvil, no será adecuado en una pantalla de escritorio. Con todos estos cambios de tamaños, nuestros textos se modifican constantemente, es así que al diseñar para responsive debemos controlar cómo fluctúan los mismos entre las resoluciones.


En CSS existen varias maneras de darle tamaño a los textos las más comunes son:
  • PX: píxeles
  • PT: puntos
  • EM: em es la anchura de la letra mayúscula "M" en el tipo de letra dado

CSS divide las unidades de medida en dos grupos: absolutas y relativas. Las medidas relativas definen su valor en relación con otra medida, por lo que para obtener su valor real, se debe realizar alguna operación con el valor indicado. Las unidades absolutas establecen de forma completa el valor de una medida, por lo que su valor real es directamente el valor indicado.

Las medidas absolutas en CSS son el Pixel y el Punto. Los navegadores establecen por defecto el tamaño de 16 pixeles, 16 píxeles equivalen a 12 puntos. El tamaño para textos en web debe aproximarse a los 16px ya que es el equivalente a los 12px en la impresión en papel. Las pantallas están más alejadas que el libro, además que es preferible subirle el punto a tener que adoptar una mala postura para poder leer el texto.

Las medidas relativas son el "porcentaje, em y rem", como dice la definición debemos establecer una medida base para que la medida sea calculada en base a esta.

Al  usar “Media Queries” con unidades de medida relativas  para cambiar los tamaños de texto, solo tendríamos que cambiar el tamaño en un solo elemento base y  automáticamente los demás elementos con unidades relativas se ajustarán basado en el nuevo tamaño.

Medidas EM

Recordemos que las medidas relativas  definen su valor así :

definen su valor en relación con otra medida, por lo que para obtener su valor real, se debe realizar alguna operación con el valor definido”.

En el caso de em su valor es relativo al “font-size” del padre directo ó del padre más cercano, esto quiere decir que cualquier cambio del CSS en cualquier nivel del DOM hace que 1em adquiera el valor de “font-size” del padre.

Por ejemplo si no definimos ningún “font-size” en nuestro css, el valor por defecto será de 16px que es el valor que asigna el navegador, por lo tanto 1em equivale a 16px.

1em = 16px
1.5em = 24px
2em = 32px
ect..

Pero podemos modificar el valor por defecto de 16px de los navegadores, por lo tanto el valor de em usaría ese valor como base, en el siguiente ejemplo podemos ver como se ha cambiado el “font-size” a 1.375em en la etiqueta html, haciendo que las demás medidas se ajusten de acuerdo a este como base por la herencia.

En este link podemos ver un ejemplo:

Para calcular el valor de las unidades em usamos la siguiente fórmula :

1em * 16px = 16px

Una técnica muy usada para no estar haciendo tanto cálculo, consiste en bajar el porcentaje para que el valor en píxeles nos de 10px. Consiste es ajustar el tamaño del “font-size” en el body para que sea equivalente a 1em =  10px en lugar de los 16px por defecto, de esta manera es más cómodo ajustar nuestros tamaños en ems. El valor de 62.5% equivale a 10px;

body { font-size:62.5%; }
h1 { font-size: 2.4em; } /* =24px */
p  { font-size: 1.4em; } /* =14px */
li { font-size: 1.4em; } /* =14px */

El problema de usar em es que se basa en herencias. Entonces si por ejemplo en una etiqueta p tengo un “font-size” y asigno el mismo “font-size” en la etiqueta span por ejemplo, span hereda el tamaño de p como su base para em. Entonces hay que estar ajustando medidas todo el tiempo, ejemplo:

<style>
html {
   font-size:62.5%;
 }
p, span{
    font-size:1.6em;
 }
</style>
<p> texto texto texto <span> Holaaaa </span> </p>
 
p tendría 1.6em el cual lo hereda a span y este lo tomaria como base para sus medidas em.

Para resolver este problema con CSS 3 ahora tenemos rem.

Medidas REM

Rem significa Root em y se basa en que con sólo declarar el rem base al elemento html las medidas siguientes no dependerán de la herencia sino del número base que hayamos declarado. Mientras em es relativo al “font-size” del padre directo o mas cercano, rem solo es relativo al “font-size” del elemento html.

Podemos definir el “font-size” del html y definir el resto de los medidas en rem basados en el porcentaje de este.

html { font-size: 62.5%; }
h1 { font-size: 2.4em; } /* =24px */
p  { font-size: 1.4em; } /* =14px */
li { font-size: 1.4em; } /* =14px */

El sorporte de rem es bastante decente hoy en dia : http://caniuse.com/#search=rem

Otro uso muy interesante es por ejemplo para márgenes ó padding relativos, digamos que queremos usar “font icons”, en el header de nuestra web y estos tienen un valor de margin-top de 20px. 

 Podemos usar un valor relativo en “font-size” en los iconos para ajustar el tamaño de estos, lo cual hará que se ajusten dinámicamente cuando cambiemos el valor del elemento base, pero el margin-top siempre será de 20px porque  tiene un valor absoluto.  Lo ideal seria que el margin-top se ajuste en dependencia del tamaño del icono.  Lo que tenemos que hacer es usar medidas relativas en el margin-top ya sea em o rem de esta manera se ajustara en concordancia con los tamaños de los iconos.

Cual debo usar em ó rem ?

La respuesta a esta pregunta es como la mayoría de las cosas, es opcional y depende de las preferencias del programador, debemos usar con la que mas nos sintamos cómodoss y la que menos dolores de cabeza nos produzca.

Medidas relativas con Media Queries

Ahora si queremos ajustar el tamaño de nuestro contenido basado en los tamaños de pantalla podemos hacer uso de las “Media queries” de la siguiente manera. Tomando los ejemplos anteriores como partida podemos ver este sencillo ejemplo:


body {
    font-size: 1.2em
}

@media (max-width: 1000px) {
 body { font-size: 1.375em  }
}

@media (max-width: 500px) {
 body { font-size: 1.6em  }
}

De esta manera todos los elementos con medidas relativas em heredan de body por lo tanto al cambiar el “font-size” de body se calcularán con este valor como base.

Usar  "em" para Media Queries en lugar de  "rem"

¿Porqué? porque el valor que obtiene "em" en Media Queries es relativo al user agent(valor por defecto del navegador ), no al estilo CSS que definimos. Por lo que si usas "rem", que debe tener una base definida en el CSS, nunca tomará esa base definida, sino que siempre tomará la medida 16px o 14px según el navegador, cosa que no podemos controlar.

Esto es debido al especificacion de la w3 :

Relative units in media queries are based on the initial value, which means that units are never based on results of declarations. For example, in HTML, the ‘em’ unit is relative to the initial value of ‘font-size’.

El uso en las de las medidas relativas no solo se pueden limitar al “font-size” en el uso de las “Media Queries”, también las podemos usar como valor para margin, padding , width y height incluso en las mismas “Media Queries” ya que tomarán como base los 16px por defecto del navegador y se aplicarán las mismas reglas. Por ejemplo:


p { 
  width: 46.25em
  font-size: 0.750em;
  line-height: 1.5em;
  margin: 1.5em;
}

/* landscape phone and portrait tablet (>= 480px < 960px) */
@media screen and (min-width:30em) and (max-width:59.9999em) {
}

/* bigger monitor (>= 1440px) */
@media screen and (min-width:90em) {
}

/* big monitor (>= 1920px) */
@media screen and (min-width:120em) {
}

Pero hay que tener mucho cuidado de saber siempre cual es valor por defecto de “font-size” en los navegadores, ya que en algunos navegadores puede ser diferente de 16px. Por ejemplo en safari mobile he leido que es de 12px.

Usa esta herramienta para saber que tamaños usar en tus medidas relativas: http://type-scale.com/

Encontre un post en stackoverflow donde resolvieron este problema con este código:

body {
    -webkit-text-size-adjust:none;
    -moz-text-size-adjust:none;
    -ms-text-size-adjust:none;
    -webkit-text-size-adjust:100%;
    -moz-text-size-adjust:100%;
    -ms-text-size-adjust:100%;
}



El uso de medidas relativas en responsive design puede ser todo un reto, pero tenemos que empezar a pensar de esta manera, ya que el “pixel perfect” ya no existe.

Nota final: ( Antes de usar rems y ems por favor revisa la compatibilidad en móviles, por que al parecer hasta este momento de escribir este articulo, el soporte en móviles es muy pobre, por lo tanto usar con precaución )


A continuacion dejo links que considero importantes leer sobre este tema, mi post esta basado en todos ellos.



http://www.paneek.net/