¿Es una molestia innecesaria, una práctica obsoleta o realmente mejora la experiencia de usuario?

Algunos argumentos para defender su existencia:

• Existe más seguridad de que el usuario ingresó correctamente su contraseña debido a la redundancia del campo.
• En el campo “contraseña” sólo se ven asteríscos o puntos, por lo que es lógico que el usuario pueda cometer errores.
• Los usuarios estan “habituados” a completar ese campo, es desde hace tiempo una convención.

Argumentos por los que pienso que ya no es necesario:

• ¿Por qué duplicar la molestia de completar ese campo a todos los usuarios, cuando quienes escriben incorrectamente su contraseña es una minoría?
• Se duplican las posibilidades de cometer un error al ingresar por segunda vez la contraseña en el campo de comprobación, lo que obligaría a repetir la acción nuevamente sin necesidad.
• Si hubo un error al crear su contraseña, siempre podrá recuperarla. Para eso existe el link o sistema de recuperación del sitio.
• El formulario es más amigable para ser completado, puesto que hay menos requisitos, menos opciones, se ve más “corto” y se completa más rápidamente.
• Existen diversas soluciones del lado del cliente (como Javascript) que transforman temporalmente los asteriscos o puntos en caracteres legibles, reduciendo la posibilidad de errores.
  
  Como podemos ver también en este ejemplo

La propuesta:

1. Durante el registro (como se ve en el ejemplo anterior), sin campo de comprobación, se permite temporalmente la vista de la contraseña.
2. Después de finalizado el registro, se envía un mail para validar la cuenta al correo electrónico ingresado y en el mismo se puede incluír la contraseña elegida por el usuario, de modo que tenga un registro para que en caso de un error de tecleo, el usuario pueda ingresar sin problemas.
3. El link de validación incluído en el mail podría iniciar la sesión automáticamente para evitar cualquier frustración inicial.

Otro sitio de prestigio como A list apart o eminencias, como Jakob Nielsen, referente de la usabilidad web, han publicado ya críticas y alternativas respecto de cómo viejas prácticas heredadas en el tratamiento de la seguridad web, como el enmascaramiento de las contraseñas (en inglés), pueden ser perjudiciales a la usabilidad y por ende a tu negocio.

Ejemplos de sitios que no utilizan la redundancia del campo contraseña:

LinkedIn

Dropbox

MailChimp

Twitter

Wunderlist

Tumblr

¿Es hora de cambiar las convenciones?¿ Qué piensan?

Es por esto que se crearon alternativas que complementan al CSS como LESS y SASS que, en resumen, te permiten escribir el CSS que usas todo los días pero con la posibilidad de utilizar variables, funciones y métodos para que tus hojas de estilo funcionen de manera mas inteligente y mejoren tu productividad.
Nativamente ningún navegador soporta éstos formatos claro, es por eso que debes convertirlos a archivos CSS comunes antes de usarlos en producción.

Suena complicado, pero hey, a no asustarse que no es tan difícil como parece, y esto créeme puede aliviar MUCHO tu trabajo diario.

¿Que puedo hacer con LESS?
Mejor que explicar será mostrarte algunos ejemplos rápidos que te permitirá entender su poder, ya que lo que se puede hacer es mucho más de lo que puedo cubrir en este post.

Variables:

En vez de manualmente agregar por ejemplo el color a cada elemento que lo requiera, puedes definir una variable y asignarle un color, luego aplicar la misma a cada elemento que lo necesite (y modificarla en otra regla), si mas tarde necesitas cambiar el color de todo el sitio, sólo debes modificar la variable inicial. ¿No es genial ?

Mixins:
Permite agrupar varias lineas CSS de una misma regla y usarla dentro de otras, por ejemplo:

Otro ejemplo clásico de Mixins es para aplicar efectos de css3 como border-radius, box-shadow, etc que requieren muchas líneas de prefijos de distintos navegadores para garantizar compatibilidad. Con LESS los podemos definir una vez y reutilizarlos infinitamente, además puedes usar los llamados “Mixins paramétricos“, donde pasas valores al mismo dinámicamente como si fuese una función de javascript.

Puedes ver más ejemplos haciendo click aquí

SASS vs LESS

Comentaba al principio que existe también SASS…¿Cual elegir?, bueno no hay un “vs” realmente en cuanto a potencia, ambos comparten muchas características y casi podría decirse que si sabes usar LESS, sabes usar SASS y viceversa.  ¿Cual es su principal diferencia entonces?…
La manera en que son procesados, LESS es una librería basada en javascript, por ende se procesa del lado del cliente (el navegador) para producir el CSS regular que el navegador utiliza, en cambio SASS corre bajo Ruby y se compila del lado del intérprete antes de ser enviado al navegador.
A muchos puede no gustarles los segundos extra que se requiere para que el motor de javascript del navegador procese LESS y lo convierta en CSS común, pero hay alternativas para evitar esto que explicaré luego.
Por otra parte SASS al compilarse por un intérprete Ruby necesitas tener instalado uno para utilizarlo (o algún derivado como Rails), por lo que si no usas ese lenguaje no podrás usar SASS, a menos que tengas una Mac que viene con Ruby de fabrica (sudo gem install sass), por lo que muy probablemente sea mas sencillo si usas pc inclinarte por LESS.

LESS primeros pasos:

¿Cómo lo instalas? Hay dos formas básicamente, o lo procesas “al vuelo” en el navegador o lo puedes compilar antes de subir los archivos a tu sitio (Recomendado)

Usando LESS  (compilando en el navegador)

• Descarga LESS de la página oficial: http://lesscss.org
• Enlaza tus hojas de estilo .less con el valor “rel” a “stylesheet/less”.
   link rel="stylesheet/less" type="text/css" href="styles.less"
• Incluye el script:
  <script type="text/javascript" src="less.js"></script>

  (Asegúrate de incluir las hojas de estilo antes del script)

Personalmente prefiero utilizar el próximo método, para ésto se requiere compilar los archivos LESS a CSS antes de utilizarlos en el sitio web, ésto hace WinLess.

Este programa, gratuito, lo hace casi todo solo. Una vez que instalas el programa y lo abres, debes seleccionar en qué carpeta de tu proyecto estarán tus archivos con extensión .less y voila!…WinLess compilará todos los archivos a CSS cada vez que los modifiques en tu editor html automáticamente, lo cual tiene la ventaja que no tienes que cambiar la forma en que enlazas a tus hojas de estilo en el header, ya que usas los archivos compilados con extensión .css como de costumbre.

Usando LESS (compilado previo a producción)

• Descarga WinLess: http://winless.org/
• Agrega tu carpeta con archivos LESS al programa
• Listo, enlaza los archivos compilados CSS como de costumbre al header de tu página

Mas información:

Less: http://lesscss.org

Sass: http://sass-lang.com

WinLess: http://winless.org

Espero te haya sido de utilidad este post y cualquier consulta no dudes dejar tu pregunta en este mensaje. Hasta la próxima !

• Git
• Ruby
• Rubygems
• Rails

Instalar Git:

Para trabajar con Ruby on Rails, el sistema de control de versiones Git, podría decirse que no es opcional, te lo encontrarás en diferentes situaciones, por lo tanto, es importante que lo tengas instalado desde un comienzo. Para comprobar si ya lo tienes instalado y su versión, en un terminal (consola), introduce la primera línea y deberías obtener la segunda o algo parecido:

Si no fuera así, sigue las instrucciones de la version online del libro Pro Git (cap. 1-4) para instalar en Linux, Mac o Windows.

A continuación nos dividimos, primero explicaré la instalación para Linux o Mac y al final la de Windows, que es mucho más fácil (sí has leído bien).

Instalar Ruby en Linux o Mac

Como con Git, primero comprobaremos si ya tienes instalado Ruby introduciendo en el terminal:

Si no tuvieras instalado Ruby, las versiones más recomendables para instalar son 1.8.7 o 1.9.2, puedes instalar más de una versión a traves de una excelente herramienta llamada RVM (Ruby Version Manager) que además permite tener distintas librerías, llamadas gems y agruparlas por ejemplo, por proyectos para mantener el entorno ligero y ordenado. No es obligatorio para el taller pero lo recomiendo totalmente.

Ahora instalar cualquier version de Ruby es tan fácil como

En caso de que no queráis instalar RVM, la instalación directa de Ruby para distintos sistemas operativos podéis encontrarla en el sitio web de Ruby.

Instalar Rubygems

Si has seguido mi consejo, y has instalado RVM, ya tienes Rubygems. Si no las instrucciones las tienes en el sitio web de Rubygems. RubyGems es un gestor de paquetes de Ruby y se usa para distribuir todo tipo de programas y librerías, como por ejemplo Ruby on Rails.

Instalar Ruby on Rails

Muy simple:

Instalación del entorno en Windows

La instalación en Windows es de broma, gracias al trabajo de Rubyinstaller y ejecutarlo.

Espero que podáis instalar el entorno sin dificultades y nos vemos el miércoles en el Digital Water Pavilion (mapa) gracias a la gente de Milla Digital.

Pero una de las mayores ventajas es que la validación del formulario se realiza en cada etapa, por lo que el visitante puede corregir algún campo mal ingresado sin tener que esperar a rellenar todos los pasos. Esto le da una agilidad al proceso y genera confianza en el visitante.

Ver demo

Para la validación del formulario, en realidad cada etapa es un formulario en si, utilizamos el FormCheck de la librería MooFloor. Éste validador se ha convertido en nuestro favorito a lo largo de los proyectos. Esta librería requiere el core de Mootools 1.2.4 y del more 1.2.4.4 sólo la clase Fx.Scroll. También incluímos un archivo con las frases del validador en castellano salvo que se quiera que aparezcan los avisos en inglés, el idioma default. Es necesario incluir un archivo CSS para mostrar correctamente los avisos del validador. Este archivo se descarga junto con el plugin javascript en la misma página. Por lo tanto la inclusión de archivos para que funcione nuestro formulario por pasos de momento queda de la siguiente manera:

Para el efecto de transición entre los pasos utilizamos el plugin SlideShow de Ryan Florence. Un plugin para hacer carruseles bastante fácil de implementar y muy extendible. La clase requiere del core de Mootools y la clase Fx.Elements del more, también la clase Loop que se descarga en el mismo sitio del SlideShow. Por lo tanto dos nuevas línea se agrega a la inclusión de archivos:

El siguiente paso es crear las estructura del formulario. Para ello creamos un DIV contenedor que va a contener a las distintas etapas. Cada etapa va a ser un FORM que a su vez va a estar contenido en un DIV. Quedando una estructura así:

En esta entrada no explicaremos como validar los distintos tipos de campos, para ello pueden visitar los documentos de la librería MooFloor.

El siguiente paso es instanciar un validador para cada paso, por lo que cada formulario tendrá su propia instancia del validador. Las opciones de la clase deberán ser cambiadas un poco a las de una validación tradicional ya que no queremos que se envíe el formulario, sino pasar al siguiente paso.

Por lo tanto las instancias del validador tendrán la siguiente forma:

Al instanciar de este modo cada validador el formulario no es enviado pero sí le realiza el chequeo para comprobar que cada campo es correcto.

El siguiente paso es el de darle el efecto de transición para pasar al siguiente formulario cuando el chequeo es válido. Para ello debemos primero instanciar la clase SlideShow y luego decirle que hacer a cada formulario cuando el chequeo es válido:

Instanciamos todos los pasos del formulario hasta llegar al último, en nuestro ejemplo el formulario ‘n’. Al validar el formulario ‘n’ se deben enviar todos los datos de los distintos pasos/formularios, para nuestro ejemplo los enviaremos mediante una llamada ajax. Recogemos la información de los distintos pasos para enviarlo como parámetro DATA en la llamada:

Ver demo

Puedes ver todo el código en github.

Espero que les guste el post. Hasta la próxima.

¿Por qué debo usar formularios HTML5?

Tres razones:

• Para el diseñador o desarrollador brinda nuevas maneras de procesar información (algunas complejas) de manera simple, nativa, sin la necesidad de recurrir a soluciones de Javascript.
• Hace mas placentera y sencilla la tarea de comprender y completar formularios para tus usuarios (si es que la palabra “placentera” puede relacionarse con “completar formularios” :/ )
• Es el nuevo standard !

Hasta ahora la forma que se utiliza para validar los formularios “del lado del cliente” es javascript para ayudar al usuario a completar correctamente los formularios para recopilar coherentemente su información, desde el registro y acceso de una cuenta hasta procesos de pago de compra y otros.

Las nuevas características para manejo de formularios html5 permiten prescindir de javascript para realizar validaciones “del lado del cliente”, esto me permite como diseñador crear un formulario completo sin recurrir a un desarrollador, aumentando la productividad, sobre todo en equipos pequeños de trabajo.

Por supuesto que hay mucho mas que validación en html5, lo veremos más abajo.

Para el usuario, los formularios tienen ahora un comportamiento más inteligente, un campo de fecha mostrará al usuario un calendario interactivo, o hints (pistas) sobre qué ingresar en ese campo, foco automático en el campo inicial, formato correcto a medidas de tiempo o seleccionar color mediante una paleta de colores.

Por último, el uso de estándares es una buena práctica, dota de profesionalismo a nuestro trabajo y asegura su funcionamiento a futuro.

Ok, vamos a los demos…¿Qué hay de nuevo?

Busca un café, Html5 agrega MUCHAS novedades, nuevos atributos, elementos y tipos de campos. Además de la explicación, incluyo un link a un demo funcional para que probemos de qué va la cosa. Los demos pertenecen al sitio Wufoo, pensaba hacerlos por mi cuenta pero realmente éstos están muy bien hechos y tienen el plus de aportar documentación adicional sobre compatibilidad e información útil.

Por cierto es recomendable que prueben las demos en el navegador Opera, pues es el que actualmente soporta mejor la mayoría de las nuevas características, también muchas funcionan bien en Chrome, Firefox y hasta en Explorer, pero varias sólo están disponibles para Opera actualmente. Pero esto no es razón para no usarlos, sino al contrario, porque no serán visibles para algunos pero les será muy útil a quienes utilicen navegadores modernos.

13 nuevos atributos:

• autofocus – Demo
  Hacemos foco en el input que tenga asociado éste valor al cargar la página
• placeholder – Demo
  Para ofrecer una pista de lo que el usuario debe ingresar
• accept – Demo
  Permite que solo el tipo de archivo determinado pueda ser cargado en el formulario
• multiple – Demo
  Permite seleccionar múltiples archivos para ser cargados de una vez por el formulario
• max / min / step – Demo
  Podemos delimitar rango de valores numéricos permitidos máximos, mínimos y  múltiplos dentro de un rango.
• form – Demo no disponible
  Este atributo nos permite colocar un elemento en cualquier parte de la página, no solamente dentro del form tag, y que éste siga siendo procesado por el form. Además permite asociar un mismo elemento a mas de un form simultaneamente
• required  – Demo
  Atributo booleano que determina si el elemento debe ser obligatorio o no
  (Utilizado junto con “pattern”, “max / min”, “email” y otros nuevos atributos, nos permite prescindir en gran medida de Javascript para validar nuestros formularios y hacero sólo con el navegador.)
  
• autocomplete  – Demo
  Permite especificar si un elemento puede o no ser autocompletado por el navegador basado en entradas previas del usuario
• pattern – Demo
  Para validar un elemento en base a una expresión regular (RegEx)
• dirname – Demo no disponible
  Envía la dirección en que fue ingresado el texto en un input determinado (ej: de derecha a izquierda)
• novalidate – Demo
  Evita la validación del elemento al enviar el formulario
• formaction – Demo
  Para sobreescribir el comportamiento por defecto del formulario
• formenctype – Demo
  Para sobreescribir la codificación por defecto del formulario
• formmethod – Demo
  Para sobreescribir el método de envío por defecto del formulario
• formnovalidate – Demo
  Para sobreescribir novalidate de un formulario (Esto es útil por ejemplo si tenemos un formulario con dos botones u acciones, uno de envío y otro para guardar cambios, pero queremos que la validación ocurra al envíar un formulario y no si el formulario es guardado)
• formtarget – Demo
  Para sobreescribir la ventana destino por defecto del form

5 nuevos elementos:

• progress – Demo
  Representa el grado de progreso de una tarea o acción (ej: Representar la carga de una imágen)
• meter – Demo
  Se utiliza para medir algo con una escala determinada, como temperatura o distancias.
• datalist – Demo
  Si asociamos un text input a un Datalist (lista de valores) al hacer foco en ese input aparece un dropdown mostrando el contenido del elemento Datalist
• keygen – Demo
  Genera un par de claves de control privada que se guarda en local y pública que se envía al servidor
• output – Demo
  Se utiliza para realizar cálculos entre campos (ej: La suma de 2 números en distintos inputs)

13 nuevos tipos de campos:

• tel – Demo
  Para un número telefónico (En realidad, no prueba que sea un número, para validar un formato numérico en particular se debe complementar con “pattern”)
• search – Demo
  Sugiere ingreso de texto en el input (La diferencia entre search y un input de texto común es que puede ser reconocido por la plataforma en la cual es visto para igualar su estilo)
• url – Demo
  Para ingresar direcciones web absolutas
• email – Demo
  Para valores únicos o múltiples de direcciónes de email
• datetime – Demo
  Formato de fecha y hora con zona horaria UTC
• date – Demo
  Formato de fecha sin zona horaria
• month – Demo
  Mes y año sin zona horaria
• week  - Demo
  Fecha para ingresar semana del año
• time – Demo
  Hora completa sin zona horaria
• datetime-local – Demo
  Fecha y hora sin zona horaria
• number – Demo
  Valores numericos
• range – Demo
  Valor numerico para controlar slider
• color – Demo
  Para elegir colores de una paleta

Conclusión:

Reflexionando sobre los cambios que esto producirá en cómo interactuamos con la web, llegué a la conclusión que el mayor cambio tal vez no lo noten los usuarios comunes (debido al actual uso de Javascript), sino los diseñadores,  aún más que los desarrolladores.

Html5 espero haga universal la implementación de muchas de estas nuevas características para hacer más entendible y simple completar formularios. Esto redundará en menos frustraciones y abandonos permitiendo al usuario finalizar existosamente su tarea. Lo cual es beneficioso para la web y una satisfacción para el cliente.

Recuerda que elementos y atributos como placeholder, autofocus, email, datalist y required, entre los más comunes, ya tienen un amplio soporte, y como alternativa, siempre tenemos la posibilidad de ofrecer una experiencia similar utilizando soporte de librerías de javascript (como modernizr) para navegadores que no soportan aún estos avances de forma tal de ir incorporando poco a poco esta nueva experiencia al diseño cotidiano.

Fuentes:

W3c Specification
* http://wufoo.com/html5/

No voy a descubrir nada a nadie, de un libro que ya es un clásico en el sector, tenéis multitud de reseñas por Internet. Pero haré, eso sí, un resumen de las ideas que se me ocurrieron al leerlo y alguna cosa con la que no estoy de acuerdo (seguramente porque no entiendo).

Ignore the real world.

Si quieres llevar una idea adelante, te encontrarás demasiado a menudo con la frase “eso en España* no va a funcionar”. Es la versión latina ampliada y empeorada de “That would never work in the real world” de los yanquis, que parece aplicarse a algo novedoso. Aquí te la puedes encontrar en todo tipo de negocios que sabemos que funcionan si lo haces bien, como por ejemplo el e-commerce.  Prepárate para ignorar muchas opiniones.

* Puedo confirmar esta frase en más países como Argentina o Italia.

¿Fallar o no fallar?

Desde hace un tiempo se oyen distintas voces que proponen e incluso basan su desarrollo en aprender de los errores o fallar a pronto y fallar a menudo, e ideas similares. Por el contrario Jason y David (J&D):
- niegan que se aprenda de los errores, porque dicen que del error sabes lo que no debes volver a hacer y no lo que debes hacer.
- niegan las estadísticas que  prueban que la mayor parte de las empresas online fracasan, porque lo que le ocurre a otra gente es sólo eso, otra gente.
- defienden que el éxito te brinda un mayor aprendizaje y que es la experiencia que realmente cuenta.
- por último arriesgan que la evolución no ha perdurado en los errores del pasado, sino que se construye sobre lo que ha funcionado.

Aquí es donde empezaron a perderme. No discuto que haya un valor inmenso en el éxito, pero gran parte del aprendizaje se adquiere a raíz de los errores, es un hecho, ese es el fundamento del método científico^W.
El dato que dice que la inmensa mayoría de las empresas de Internet fracasan, efectivamente no significa que a la tuya le vaya a ir mal, estoy de acuerdo, pero no por ello debes negarlo, simplemente estar atento y hacer lo posible por evitar el fracaso.
Y finalmente el ejemplo de la evolución es definitivamente errado y su explicación posiblemente poco interesante para el lector de este blog. No es equiparable lo que “ha funcionado” a lo largo de la evolución, con el éxito de una empresa, ya que la evolución no tiene un objetivo, ni aprende, y más bien una empresa podría compararse con la vida de un individuo, no con la evolución de las especies, la escala es fundamental. Las empresas son diferentes a los organismos cuyo genotipo no varía.
Entiendo que se trata de una metáfora y como todas las metáforas permite aproximarse a la idea pero carece de precisión. En cualquier caso se me ocurre que si quisieramos relacionar la teoría evolutiva^W con las empresas de internet es más fácil argumentar en favor del aprendizaje de los errores, ya que la selección o éxito de las empresas puede darse en distintos momentos según su capacidad de adaptarse a los cambios del ambiente.

Por último, la idea que más me gustó del libro es esta:

Las grandes decisiones son difíciles de tomar y de cambiar… Cuando tomas pequeñas decisiones no puedes cometer grandes errores…”

A pesar de alguna crítica el libro me parece excelente y muchos de sus consejos aún los estoy madurando. Si no has leído el libro y quieres saber algo más te recomiendo esta charla de TED, en la cual Jason Fried presenta las principales ideas:

Quiero agradecer especialmente a @genezeta que me ha regalado el libro, y próximamente lo dejaré libre para que cualquier otra persona lo lea y aproveche.

Gracias también por la imagen a Rafael Peñaloza.

Lo primero que llamó mi atención fue que lo recomendaba Paul Irish, uno de los creadores de la plantilla html5Boilerplate. Entonces me puse a investigar de qué se trataba.

Wow. Bones is super hot! Seriously… (Paul Irish)

A diferencia de Starkers, theme “desnudo” de todo estilo y formato, muy útil para aprender y no heredar estilos “de fabrica” de WordPress, pero que personalmente me resultaba algo lento para mi trabajo,  creí que Bones era similar, pero al interiorizarme descubrí que aporta otro enfoque.

Bones, nos brinda una plantilla sólida y optimizada, lista para trabajar, puesto que todo elemento se encuentra documentado e incluido en el css, lo que agiliza mucho el trabajo.

Bones fue creado en base a lo último en estandares HTML5,  y por supuesto es compatible con todo navegador moderno y testeado hasta en navegadores viejos como IE6 sin problemas. Es compatible con WordPress 3+ e incluye un theme default muy básico pero funcional para no tener que hacer todo literalmente desde la nada.

Así se ve el theme default cuando lo activamos por primera vez:

Estructura CSS

Cuenta con 2 hojas de estilo, primero llama a un hoja por defecto que incluye un reset.css y estilo básico (default.css) para todos los componentes del theme (por lo que es fácil restaurar valores si cometemos algún error) y luego llama a la segunda hoja de estilos: styles.css que es donde trabajaremos.

El reset esta basado en la plantilla html5Boilerplate y cuenta con algunos agregados propios de clases comunmente usadas:

Cabeceras y Titulos

Algo que me pareció bastante inteligente, muchas veces queremos que por ejemplo un h3 se vea como un h1 por cuestiones de diseño, pero por supuesto, no se debe agregar dos h1 en una misma página, por lo que terminamos agregando lineas extras de codigo, complicando la estructura. Esto con Bones se resuelve de la siguiente forma:

Entonces si queremos que un h3 se vea como un h1 agregamos el class .h1

<h1 class="h3">Esto es un H3 que se ve como un H1</h1>

Muy bonito, pero basta de pequeñeces… Vayamos a lo gordo

Grid Css

Bones cuenta con un grid incorporado al css muy flexible, permite layouts fluídos o fijos y podemos seleccionar libremente el ancho maximo y minimo del layout.
Su uso es muy simple, para agregar un ancho de 480pixels a un div, agregamos algo como:

<div id="main" class="col480">...</div>

Cada elemento de wordpress esta incluido en el css de forma meticulosa y clara, es super simple dar estilo a los elementos, incluso para páginas o posts especificos, gracias a selectores avanzados de css.

Media Queries y Especificidad

Incluye las reglas de Media Queries y móviles recomendadas por Andy Clarke (de quien escribí un post recientemente sobre uno de sus libros) para adaptar el diseño de manera “responsiva” a diferentes resoluciones y dispositivos (el uso es optativo por supuesto)

Además encontramos la técnica incluída ya en html5Boilerplate, sobre el manejo de clases para dar estilo a versiones especificas de Internet explorer sin agregar hojas de estilo extras.

Por ejemplo para dar estilo al contenedor de los post (.post_content) podemos llamar a las siguientes clases:

Extras

Por último incluye una hoja de estilo para impresión y algunos plugins para agregar video html5 que aún estan en fase de prueba y la verdad no tuve la oportunidad de probar.

Bones en números

Algunas estadisticas provistas por la pagina de Themble

Hasta ahora la experiencia ha sido muy grata, realmente me ha ahorrado mucho tiempo de desarrollo y les recomiendo que lo prueben.

¿Ya has usado Bones?, deja un comentario, me gustaría conocer tu experiencia !

Link al sitio de Bones

Echa un vistazo a esta lista de twitter de todos los ponentes de TED cuyo usuario de twitter ha sido publicado en la web de TED.com y alguno más.

Las listas de Twitter son una gran manera de mantener la información separada por tema, eventos u otros. De modo que puedes ver en un momento determinado, como pausas de Pomodoro en la búsqueda de determinado tipo de datos.

Si eres fan de las charlas TED esta lista es un recurso muy interesante. Espero que te guste:

https://twitter.com/#!/pablojimeno/ted-speakers

Por cierto estoy colaborando con la organización del evento local TED TEDxZaragoza “El futuro de la felicidad”, mantente informado:

• TEDxZaragoza sitio
• TEDxZaragoza en Twitter
• TEDxZaragoza en Facebook

Perdón, chiste trillado….Pero es una pregunta importante que debemos hacernos antes de encarar un proyecto de estas características. Elegir uno u otro camino tiene sus pro y contras, y si bien no voy a profundizar respecto a crear aplicaciones nativas, haré una introducción al tema.

Aplicación nativa es aquella que especificamente es diseñada para funcionar en el sistema operativo de ese dispositivo.

Esto tiene sus ventajas:

• Acceso al hardware del dispositivo
• Capacidad para funcionar sin conexión web (aunque gracias al Html5 ahora es posible lograr una funcionalidad similar, lo explico luego.)
• Performance y velocidad
• Posibilidad de monetizar la aplicación (Por ejemplo vender tu app desde el appStore)

Estas ventajas por supuesto son importantes, pero requieren de un desarrollo específico por cada plataforma (Android, Iphone, Symbian, Blackberry, etc), a veces inclusive más de una versión, y una inversión de recursos de hardware, y mayor tiempo y conocimientos de desarrollo.

Por otra parte, si optamos por HTML5, CSS3 y Javascript como opción de desarrollo tenemos un camino diferente.

Podemos utilizar reglas de CSS3 y aprovechar características HTML5 + Javascript para controlar el comportamiento de nuestro sitio o aplicación de teléfono móvil y ofrecer una grata experiencia al usuario sin preocuparnos por tantas variables.

Con Media Queries podemos evaluar unos pocos parámetros universales que cualquier dispositivo actual tiene (hay más, pero sólo éstos nos interesan en este caso):

• Ancho y alto del navegador
• Ancho y alto del dispositivo
• Orientación del dispositivo (Ejemplo, evaluar si un iPad se encuentra en modo landscape or portrai)
• Resolución del dispositivo

Ejemplo:

@media all screen and (max-device-width: 600px) {#container { width: 550px;}}

Con esta simple regla estamos diciendo que si el dispositivo que carga nuestra página tiene un ancho máximo de 600px entonces le aplique al div “container” un ancho de 550px.

De esta forma podemos controlar cómo se visualizará nuestro sitio web o aplicación en diferentes resoluciones, no sólo de teléfonos moviles sino también ordenadores de sobremesa, notebooks y netbooks con mínimo esfuerzo.

Aquí pueden ver un ejemplo práctico de una aplicacion web que recientemente desarrollamos para un cliente, llamada Tivifan en la que utilizamos esta técnica, y notarán en las capturas como el diseño se adapta a los diferentes dispositivos:

Monitor de sobremesa:

Esta es la vista del sitio “normal” en un monitor con resolución alta.

Ipad en modo portrait: el sitio se muestra correctamente, pero en una sola columna, dando mayor espacio y comodidad al contenido principal.

Ipad en modo landscape: Al tener mayor espacio, mostramos el sitio a dos columnas.

Móvil con Android: A menores resoluciones, como la de éste dispositivo, toda la estructura del sitio es modificada. Navegación, logo y formulario mas pequeño y simplificado, fuentes reducidas, contenido a una columna, etc. Aunque menos atractivo que las otras opciones el sito es plenamente usable y su contenido más importante sigue siendo accesible.

Puedes probarlo tu mismo desde aquí, simplemente cambiando el tamaño de tu navegador manualmente.

Otras métodos interesantes: Antes comentaba que una ventaja de aplicación nativa era la capacidad de trabajar off-line, esto con HTML5 es también posible, gracias a la capacidad de guardar datos de forma local. Una de las opciones es utilizar localStorage. Permite definir algunos campos en lo que se puede describir como una simple base de datos en el navegador y recuperar un valor, incluso cuando el usuario ha cerrado su navegador y lo vuelve a abrir más tarde.

Haz la prueba y juega con este ejemplo online creado con HTML5 y Javascript desde el siguiente link:

http://jsbin.com/alagur/3/edit

Este por supuesto fue apenas un vistazo del potencial de HTML5, javascript y CSS3 para el desarrollo de aplicaciones y sitios web para teléfonos moviles. Muy pronto, más…

Más información de localStorage y Media Queries:

Media Queries

LocalStorage en Quirksmode

Primero que nada “no leí el libro del que habla el vídeo, pero lo haré pronto porque me han convencido”.

Una de las cosas que siempre intento mejorar en mi equipo son las retrospectivas. Si no sabes lo que son, probablemente este post no es para ti, en cualquier caso:

La retrospectiva es una reunión especial en la cual el equipo se junta después de haber completado una iteración o porción incremental de trabajo y adapta sus métodos y trabajo de equipo.

En equipos que desarrollan mediante métodos iterativos incrementales, las retrospectivas al final de cada iteración estimulan la mejora continua a lo largo del proyecto.

Hace un tiempo encontré esta presentación a cargo de Esther Derby (@estherderby) y Diana Larsen (@dianaofportland) una excelente explicación de su enfoque de 5 pasos para realizar retrospectivas, basada en su libro “Agile Retrospectives: Making Good Teams Great”. Resumiré básicamente los puntos más importantes de la charla, pero puedes saltarte esta parte y ver tú mismo el vídeo.

Este es un proceso continuo y enlazado que simplemente fluye al final de cada iteración, hacia la retrospectiva. El framework que proponen consiste en completar siempre la siguiente secuencia de 5 etapas o porciones de trabajo:

1. Establecer el escenario.
2. Reunir datos o información.
3. Generar ideas.
4. Decidir qué cosas hacer.
5. Cerrar la retrospectiva.

1. Establecer el escenario.

Establecer el marco para el trabajo que se va a realizar durante la retrospectiva. Por ejemplo: establecer el objetivo de esta retrospectiva, presentación de los asistentes, acuerdos o compromisos de trabajo, marcar el enfoque que tendrá la sesión, etc.

2. Reunir datos o información.

Estamos educados para analizar y procesar datos como individuos en un ambiente en el cual compartir ideas a veces equivale a copiar (hacer trampas).

Una de las razones por las que los equipos suelen discutir en procesos como la retrospectiva o la planificación, es porque no están acostumbrados a pensar juntos. Es por eso que recopilar datos es una de las primeras cosas que deben hacerse en este proceso de comenzar a pensar en equipo. Recopilamos datos no sólo sobre hechos sino también sobre sentimientos (aunque no debe usarse esta palabra sino Energía o algo menos emocional que no inhiba a nadie) para analizar cómo se sintió el equipo durante la iteración.

3. Generar ideas.

Una vez que tenemos los datos es hora de preguntar “¿Cómo llegamos a este punto? ¿Cuáles son las causas y patrones? ¿Qué nos dicen estos datos sobre el modo en que trabajamos?”

Un método para hacer esto lo denominan “la matriz de aprendizaje”, consiste en dividir un folio en cuatro cuadrantes y escribir:

• :) qué fue bien
• :( qué no fue tan bien
• *-:) (bombilla) ideas o cosas para hacer de otra manera
• ⚘ (flores) reconocimientos

4. Decidir qué cosas hacer.

Buscar acciones concretas que tomar en la siguiente iteración, no deben ser demasiadas iniciativas, uno o dos experimentos y asegurarse de analizarlos en la siguiente retrospectiva.

5. Cerrar la retrospectiva.

Finalizar la retrospectiva de manera contundente: no permitir que haya cosas que se cuelen hacia otras reuniones. Hacer una retrospectiva de la retrospectiva y cerrar la sesión.

Estas son algunas ideas que quería puntualizar del vídeo, por supuesto están mucho mejor expuestas y con mayor detalle en él, te recomiendo que lo mires, está en inglés y sin subtítulos.

Referencias:

Agile Retrospectives: Making Good Teams Great (Pragmatic Programmers)

La imagen es propieda de LIFE