Revisando los diseños de formularios que últimamente pasan por mis manos no está de más revisitar las técnicas que nos permiten "poner bonito un input file".

Las más populares son la clásic de shaun inman, y una elaborada por Michael McGrady (según PPK). Por mi parte estoy mucho más de acuerdo esta última, aunque creo que si la vamos a usar varias veces en un proyecto necesitamos que sea un poquito más flexible.

He escrito un plugin pequeñito que hace el trabajo sucio y nos permite centrarnos en estilizar el input file falso y no en todo lo demás. Depende de jquery porque la mayoría del tiempo trabajo con este framework, pero sería fácil dejarlo limpio de dependencias.

Por el momento funciona, echadle un vistazo a la demo :)

El código fuente lo podéis encontrar en su correspondiente repositorio en github..

Hace unos días andaba buscando alguna solución que cuadrase para la interfaz de la zona de clientes de la web de The Cocktail. Los requerimientos eran fáciles: teníamos una lista de proyectos tagueados con el sector al que pertenecen (ocio, servicios financieros, educación) y con las áreas que han intervenido (front, back, marketing, hci...) y teníamos que poder filtrarlos combinando ambos parámetros.

Sin rascar demasiado encontré filterable, y la verdad a simple vista parecía cuadrar así que me guardé el enlace y seguí trabajando. Cuando me tocó ponerme manos a la obra entendí que filterable sólo me iba a servir como inspiración para empezar a trabajar.

Ya con el filtro de The Cocktail hecho empecé a pensar que seguro que podía hacerlo un poquito más genérico y darle un poquito más de alma. El resultado es jquery.filterprojects, un plugincillo que facilita esta tarea y que no está especialmente atado a la sintaxis de tu html.

Puedes personalizar unas cuantas cosillas:

• filterTagSelector: Debe de ser un array con una colección de enlaces cuyo href sea el tag a filtrar (href="#enanos-de-jardin")
• animationSpeed (900): Puedes ajustar la duración de la animación que se va a ejecutar al filtrar
• animationPulse (100): Esto me encanta :) Es el tiempo que va a dejar entre el comienzo de cada animación, hace el efecto menos mecánico. Si prefieres todo al mismo tiempo pon un 0.
• animationEase ("linear"): puedes usar también "swing" o instalar cositas extra para poder aplicárselo al animate.
• activeClass ("active"): Qué clase vas a usar en los selectores de filtrado cuando esté la clase activa.
• allTag ("all"): Es el tag que queremos usar en los selectores de filtrado para decir que seleccione todos los tags del grupo
• randomize (true): Hace que al filtrar los elementos estos aparezcan y desaparezcan en ordern aleatorio. Si tenemos animationPulse a 0 no se nota nada :)
• show: ({ width: 'show', opacity: 'show' }): parámetros para mostrar los elementos, basados en los necesarios para animate.
• hide: ({ width: 'hide', opacity: 'hide' }): parámetros para ocultar los elementos, basados en los necesarios para animate.

Y la sintaxis es facilita:

 
 $("#posts").filterprojects({  
    animationSpeed: 1000,  
    animationPulse: 80,  
    randomize: false,  
    show: { height: 'show' },  
    hide: { height: 'hide' },  
    filterTagSelector: [ '#issues a' ]  
  });  
 
 

Pero como esto es mucho más fácil verlo que contarlo (como siempre) échale un vistazo a estas demos o descárgatelo en github. Durante los próximos días le casco unos tests, le paso la podadora y le amplio la documentación.

Me lo disfruten :)

Hace ya un tiempecillo que terminé este pequeño experimento y todavía no había dejado nada por escrito aquí (si hasta le he hecho un site!).

Reticulatorjs es una pequeña librería que te permite poner una retícula encima de la maqueta que estés realizando.

La idea era fusilar el Reticulator para Fireworks de Ale (actualmente dentro de OrangeCommands) y trasladarlo al entorno web. Cuando un diseñador marca una retícula le encanta que se la respeten al traducir su trabajo a html y muchas veces unas guías son más que suficientes para ver si vas bien o no.

Si la descargas puedes configurártela al gusto y poner guías horizontales y verticales. Si eres vaguete (como yo) puedes configurarlo a través de un bookmarklet o usar un bookmarklet preconfigurado.

Se puede configurar prácticamente todo: color, opacidad, columnas, gutter... y además puedes activar y desactivar la retícula creada pulsando g+r.

Siente libre de 'forkear' el repo en github, como hizo el majísimo de Choan, que tras unas semanas en funcionamiento me envió un pull request que prácticamente lo reescribía todo :D

No me enrollo mucho por aquí, es mucho mejor verlo en marcha, así que os invito a que os deis una vueltecita por los ejemplos :)

Sobre el papel Google Website Optimizer parece una herramienta de marketing estupenda. Nos permite definir unos objetivos y probar distintos contenidos o alternativas de una misma página para ver qué funciona mejor. El problema es que para ponerlo en marcha hacen falta dos ingenieros de caminos algunos conocimientos técnicos.

Tras seleccionar los objetivos google nos da huellas javascript para poner en cabeceras, pies, rodear secciones... Esta página da verdadero pavor la primera vez que la ves. No es de extrañar que antes de asustarte pregunte si lo vas a instalar tú o vas a contar con un equipo técnico para instalarlo.

Como miré en mis cajones y no encontré ningún 'web team' me imaginé que esto iba a tener que acabar probándolo en mis propias carnes, así que pensé ¿que haría McGiver?, o mejor, alguien más vago ¿qué haría Porras?. Evidentemente algo que me quitase de trabajar más de una vez en esto.

Buscando lo que había hecho por ahí encontré este plugin, que incorporaba unos helpers monísimos pero no me valía por tres cositas:

• GWO es para usarlo una temporadita, decidir qué contenido es el que nos da mejor rendimiento y olvidarlo. Así que si puedo evitar modificar la aplicación mejor.
• Tengo que incluir scripts concretos en páginas concretas. Si todas mis páginas comparten layout y quiero tener varios experimentos activos al mismo tiempo me toca montar la fiesta del 'elsif' o alguna similar, y... si puedo evitar modificar la aplicación mejor.
• Si esto del GWO al final es buena idea, que parece que sí, van a querer usarlo en más sitios, y si yo o cualquiera de los agraciados podemos evitar modificar las aplicaciones... mejor!

Así que lo descarté y traté de construir algo que cumpliese con todo lo anterior.

Y de la vagancia más absoluta ha salido la primera versión de gwo_on_rails, un pequeñisimo plugin que te permite integrar este servicio tirando de un triste (pero bonito) yaml.

Está por limpiar, refactorizar y podar, amen de hacer tests más robustos, pero la realidad es que simplifica bastante el trabajo y ya está funcionando en un site en producción, en una home, a las mil maravillas sin modificar para nada la aplicación: instalar y rellenar el fichero de configuración.

¿Se puede pedir más? seguro que sí, hay partes que seguro se pueden resolver de formas más eficientes y otras que se a ciencia cierta que son un poquito matar moscas a cañonazos, así que cualquier sugerencia para mejorar el plugin será recibida con los brazos abiertos.

Composición:

Esta vago-receta necesita de un poquito de preparación. Debemos de instalar la gema w3c_validators. Una vez hecho eso necesitaremos copiar este cachito de código en un archivo Rakefile en la raiz de donde tengamos nuestras maquetas. Si ya tenemos un Rakefile sólo añadiremos la tarea:

 # # Massive html validation task
 # 
 # This rake task comes from the nanoc validation task (http://gist.github.com/8961)
 # Copy this Rakefile to the root of your htmls or add the task to your existing Rakefile 
 # and run:
 # 
 #   rake validate
 # 
 # and that's all :)
 
 task :validate do
 
   require 'w3c_validators'
   include W3CValidators
 
   desc "W3C validation of all the files of the current folder"
   task :validate do
     validate '.html'
     # add validate '.theextensionofyourhtml' to extend this task
   end
 
 
   private
   
   # Colorize your output :) 
   def colorize(text, color_code); "#{color_code}#{text}\e[0m"; end
   def red(text); colorize(text, "\e[31m"); end
   def green(text); colorize(text, "\e[32m"); end
 
   # Validation calling to the w3c_validators methods
   def validate ext
     @validator = (ext == ".css" ? CSSValidator.new : MarkupValidator.new )
 
     files(".", true, ext).each do |file|
       results = @validator.validate_file(file)
       if results.errors.length > 0
           results.errors.each do |err|
             puts "** #{file} => #{red(err)}"
           end
         else
           puts "** #{file} => #{green('Valid!')}"
         end
     end
 
   end
   
   # Stoled from nanoc :) (but with a lot of love)
   def files(dir, recursively, ext = '')
     glob = File.join([dir] + (recursively ? [ "**", "*#{ext}" ] : [ "*#{ext}" ]))
     Dir[glob].reject { |f| File.directory?(f) or f =~ /(~|\.orig|\.rej|\.bak)$/ }
   end
 end
 
  

La última versión y correcciones estarán siempre en este gist.

Si la extensión de los archivos a validar no es .html, no dude en variar la línea de la tarea donde se especifica la extensión o añada tantas líneas como sea necesario (esssto hay que mejorarlo)

Esta vago-receta no usa nanoc ni nada por el estilo. La podemos usar en cualquier carpeta llena de archivitos html.

Indicaciones:

Se indica su uso especialmente en todos aquellos casos en el que necesitemos validar el código y tengamos más de 3 htmls :)

Especialmente recomendable cuando más de un zángano guarrea sobre el código.

Posología:

Vaya hasta la carpeta raiz de su proyecto en un terminal y escriba rake validate tantas veces como sea deseable y usted obtendrá un ouput coloreadito super majo.

Cada validación tarda casi nada, pero cuando hay un buen puñado de htmls necesitamos un poquito de paciencia. Aunque bien mirado siempre es mejor que ir uno por uno.

Contraindicaciones y sobredosis:

Validar constantemente puede convertirte en un pequeño psicópata, úsalo con mesura ;)

Otras presentaciones:

Añadiendo en la tarea un validate ".css" conseguimos validar nuestros estilos. Funciona pero en hojas de estilo enormes saca cositas un poco raras.

Hace bastante tiempo intentamos usar nanoc para maquetar proyectos más o menos grandes. Era una versión muy decente, pero que necesitaba madurar. Al mismo tiempo exploramos algún otro mini framework similar como staticmatic, pero estaba todavía menos cocido.

Desde la versión 2 de nanoc el framework se ha convertido en algo bastante sólido, pero además es open souce, es extensible, el código está documentadísimo y su uso también. Si hace mucho que lo probaste tal vez deberías darle una segunda oportunidad.

Vaaale

Está claro, hay métodos más sencillos de hacer html, y que requieren menos conocimientos técnicos, quién no se acuerda de home site.

Tampoco hace falta ser ingeniero aeronáutico para manejar esto. Con tener ruby y rubygems es suficiente para instalarlo y comenzar a trabajar, y hasta ahí llegamos todos.

"Envíeme las maquetas a..."

El clásico include de php nos permite reutilizar gran parte de nuestro código, incluso introducir lógica en nuestra maquetación, nada nuevo. Pero si el sistema nos obliga a tener configurado un host o no funciona si no es bajo un servidor con unas características determinadas (más o menos comunes, eso da igual) sólo nos sirve a nosotros y a nuestro entorno de trabajo cercano.

Con nanoc tenemos las mismas ventajas pero su output es siempre html independiente del framework, de manera que podemos enviar el directorio de salida a cualquiera y lo podrá ver sin obligarle a configurarse nada, como en los viejos tiempos :)

Si son 4 comandos!

Tanto keko como Jose han hablado ya de las maravillas del tutorial de nanoc2 que escribe y actualiza el gran Ale y que nació del tallercito de maquetación ágil que vivimos hace ya casi un año.

No te voy a contar nada que no puedas ver en el tutorial de Ale o en la documentación oficial, de hecho sólo estoy rascando la superficie un poquito.

• nanoc create_site nombredelsite para crear un proyecto nuevo. Tienes muchísimas posibles combinaciones, pero los valores por defecto nos permiten trabajar estupendamente.
• nanoc create_layout nombredellayout. Hay un layout por defecto con el que puedes trabajar. Aquí el concepto de layout es también el de partial. Puedes incluir un layout que contenga, por ejemplo, la cabecera de nuestro site en el layout por defeto llamándolo <%= render 'cabecera' %>.
• nanoc create_page nombredelapagina para crear las páginas. Cada página tiene un yaml en el que le podemos definir filtros, variables a usar...
• nanoc compile hace lo necesario para juntar layout, páginas, lógica, etc... y meterlo en la carpeta de salida que hayamos definido.

Para no tener que estar compilando el proyecto a cada cambio (sí, yo también soy de los que cambia dos divs y tiene que recargar la página) existe el comando nanoc autocompile, que nos lanza un servidor, por defecto en el puerto 3000, y cada vez que entramos a http://0.0.0.0:3000/nombredelapagina recompila esa página. Este comando no funciona bien en windows al menos en esta versión, puedes ver el html generado, pero muestra las imágenes como corruptas.

Vamos, que son 4 comandos! A cambio tenemos un proyecto mucho más sostenible y hemos reducido al mínimo el impacto de los cambios sobre la maqueta.

Hay varios comandos más, pero con estos ya podrías crearte un site majísimo. ¿Merecería la pena construir una aplicación de ejemplo complejita por entregas?

Big, bigger, biggest

Lo mejor de todo es que podemos dejar nanoc como está e ir extendiendo nuestra aplicación. Lo podemos hacer a base de plugins, que son archivos .rb situados en el directorio lib o bien con rake tasks, en el directorio tasks.

Así que el límite está en tu imaginación, en tu dominio de ruby y tu experiencia con rake.

Por poner un ejemplo. Sería maravilloso que en un proyecto enorme, antes de entregar, tuviésemos una manera de validar de golpe todas las maquetas (y bola extra css).

Lo más fácil sería crear una tareita rake que analizase nuestro output por nosotros. Si copias este validate.rake (*) en tu directorio tasks podrías ir a la raiz de tu proyecto y correr rake validate. En un momentito tooooodo validado :)

(*) en el momento que escribo esto el gist de la tarea rake está fallando, así que puedes verlo aquí.

Esta y otras tareas y plugins las trataremos de colgar (y mantener) en nuestro gist, por si encontráis alguna cosilla que os resulte útil.

Si todavía tienes dudas instálalo, trastea un poquito con cosas nada comprometidas y si no encuentras respuesta a tus dudas siempre puedes unirte a la lista de nanoc en castellano.

Desde hace meses he ido incorporando de manera bastante natural a mi rutina de maquetación pequeños detalles que ayudan a que el engranaje entre la maqueta y la implementación en un proyecto web sea un poquito más sencillo. La mayoría son obviedades, sentido común fácil de incorporar a nuestro día a día.

Muchos de estos "vicios" los heredé de Álvaro y María y otros los he ido incorporando a base de trabajo y de integrar html en desarrollo, pero sobre todo a base de equivocarme mucho, que también es necesario.

Esto es lo que a mi me funciona, es más que probable que no descubras nada nuevo:

Comentar y tabular:

Un código bien tabulado siempre es más legible independientemente del lenguaje que estemos escribiendo. Si la maquetación se hace en equipo siempre está bien llegar a un acuerdo sobre el tipo de tabulación que se va a usar. Yo me encuentro cómodo con 4 espacios, pero es cuestión de gustos.

Es muy útil marcar con un comentario el final de los divs principales para siempre tener localizado dónde se cierra.

 
     <div id="content">
 
         ...
 
     </div><!-- #content -->
 

Tampoco está de más marcar con un comentario el comienzo y fin de bloques específicos, por ejemplo: <!-- ultimos comentarios --> o <!-- listado de profesores -->

Es la manera más fácil de no volvernos locos al abrir nuestro trabajo cuando ya no lo tengamos fresco.

Primero el marcado, después el estilo:

No hablo de escribirte todo el html de la página que vayas a maquetar, pero es muy fácil identificar los bloques que van a funcionar como unidad.

Pon el esfuerzo en escribir un html limpio y semántico en lugar de ir saltando entre la hoja de estilo y el html desde el principio. A mi esto me da muy buen resultado, pero hay quien prefiere ver una evolución más gradual mientras trabaja.

Mantén limpio tu html y hereda:

Todos hemos pasado una fase de 'classitis' :) Un uso correcto de la herencia nos evita este problema. Al integrar el html la mayoría de los desarrolladores son cuidadosos, pero un código limpio les facilita bastante las cosas, reduce el margen de error y es más sostenible.

Un ejemplo podría ser este:

 
 	<ul id="menu">
 	   <li><a href="#">01</a></li>
 	   <li class="active"><a href="#">02</a></li>
 	   <li><a href="#">03</a></li>
 	   <li><a href="#">04</a></li>
 	   <li><a href="#">05</a></li>
 	</ul>
 

Marcando la clase en el li en lugar de en el enlace podemos actuar sobre dos elementos para componer nuestro estilo 'active'.

Menos no siempre es más:

Se que mucha gente está a favor de poner únicamente el html necesario, ni más ni menos. Yo estoy totalmente de acuerdo siempre y cuando sepamos a ciencia cierta que un cambio en una estructura del html dentro de unos meses no va a generarnos más dolores de cabeza de los necesarios.

Con toda la cautela del mundo, a veces un div de más rodeando un bloque de contenido nos da el juego suficiente para cosas tan básicas como ajustar detalles entre distintos navegadores. Siempre es más fácil añadir un poquito más de CSS que destripar una aplicación en producción.

Aclaro que no hablo más que de un poquito, un elemento para ajustar padding, para dar un sobrefondo en un momento determinado, etc, no estoy justificando un chorro de sobre-html que se pega con la filosofía de mantener el código lo más limpio posible.

Establece algún criterio de calidad:

En todas las fases de un proyecto deberían de haber reglas de control que nos ayudasen a asegurar que nuestro trabajo sea lo suficientemente bueno. El criterio de calidad más usual en el caso de la maquetación es el de validar tanto html como CSS.

Que un código valide no significa que esté bien, pero sí que no se nos ha olvidado cerrar ninguna etiqueta.

Esto nos lleva a otro criterio más, que es probar nuestro trabajo en los navegadores que exija la ruta del proyecto, que por lo general suelen ser 4 - 5.

Yo además, siempre que es posible paso trozos complicados de código a compañeros de trabajo o de fatigas para tener siempre una segunda opinion, que normalmente no es objetiva, pero que nos aporta un punto crítico.

Usa convenciones:

Usar patrones en esquemas básicos que se repiten a lo largo de todo un site nos facilita el trabajo a nosotros y a los integradores.

El ejemplo más fácil de explicar sería el de marcar el elemento activo en un menú. Normalmente tenemos una navegación principal y una secundaria al menos. Pues podríamos convenir que los menús siempre son listas, y que el elemento activo se va a marcar en el li con una clase 'active'.

Minimiza el impacto de los cambios:

Quiérete a ti y a los que te rodean y utiliza todos los medios que tienes a tu alcance para no perder ni tu código ni tu tiempo.

Mete todo tu código en un control de versiones. Da igual el que sea, el que más fácil te resulte o el que menos infraestructura vaya a requerir. Los más famositos son subversion, csv y últimamente está muy e moda git. Dedicale un ratito a aprender los 4 comandos básicos y nunca vuelvas a perder un solo archivo.

Utiliza herramientas que te ayuden a hacer el trabajo mecánico. Todos hemos recibido un cambio en la cabecera en un proyecto en el que ya hay 50 maquetas ya hechas :) Si hacemos un reemplazo masivo corremos el riesgo de cambiar lo que no debemos. Si hacemos el cambio en una sola maqueta y avisamos de dónde está el cambio vía mail / viva voz / paloma mensajera corremos el riesgo totalmente innecesario de que el que finalmente va a trabajar con las maquetas no reciba el recado.

Cualquier método que nos permita trabajar con el concepto de 'include' nos puede valer, pero los más útiles son los que generan html estático. Una buena solución si no le tienes miedo a programar un poquito sería nanoc, que además está bastante documentado.

Intercambia conocimientos:

Habla con la gente que trabaja contigo, intercambia opiniones, trata de conocer sus problemas a la hora de afrontar lo que tú les vas a enviar porque es la mejor manera de que todo salga bien.

Discute con otra gente tus métodos. Hace unos días tuvimos una pequeña reunión varios compañeros para poner en común formas de trabajar y surgieron temas interesantísimos que no salen de ninguna otra manera.

Todos los puntos anteriores son matizables, incluso algunos totalmente prescindibles, pero son un buen comienzo :)

Ya le he dado algo de rodaje al plugin y creo que se puede sacar. Toda la explicación de qué es el plugin, para qué, y cómo funciona está en el post anterior, así que no me repito.

Esta release (totalmente beta) la podeis instalar en vuestro mephisto:

Si quereis curiosear código pasaos por este svn (si dreamhost os deja).

Creo que no hace falta decirlo, pero cualquier feedbak será bienvenido.