Entre diseñadores web y desarrolladores web siempre ha habido una línea un tanto difusa entre las funciones de uno y las funciones de otros. En esa línea difusa aparece el perfil de maquetador que en muchas empresas recae entre las funciones de uno o de otro.
Si nos ponemos tiquismiquis podemos sacar muchos más perfiles, pero para este artículo nos bastará con estos 3 :D
Proceso de creación
Para entendernos un poco mejor, explico lo que entiendo por un proceso de creación de una aplicación web, partiendo de que se haya hecho (o no…) un buen análisis, con su correspondiente toma de requerimientos y si ya estás en una empresa seria de verdad, un proceso de validación de prototipos, y especificaciones… pero solo si es una empresa seria de verdad, no vale con ir de ello…
En ese punto, una vez aprovado todo por el cliente, remarcado y explicado perfectamente lo que se ha pedido y lo que se ha de entregar, se comienza a trabajar.
En este punto, los diseñadores empiezan a darle forma a esos prototipos, esos wireframes que el usuario a validado y que espera recibir. Una vez terminados estos diseños, generalmente en formato imagen, se le muestran al usuario para que valide el diseño de la página y pasemos a darle funcionalidad a la misma. (Ojo!, creo que estoy entrando en un mundo utópico rodeado de unicornios y dragones… 
).
Vale, ya hemos validado con el usuario el diseño y la funcionalidad que desea para su nueva y flamante nueva aplicación web, ha sido un proceso duro, pero nos permite disponer de toda la información necesaria para empezar y no tener que volver a molestar al usuario, salvo las notificaciones periódicas que se planifiquen.
En este punto, el diseño se pasa a los maquetadores, encargados de convertir ese diseño en el HTML que el usuario podrá ver en su navegador, este HTML no contendrá ninguna funcionalidad, únicamente habrá HTML y CSS.
En este punto, entramos una zona pantanosa, ya que nos encontramos código javascript que necesita el diseño para ser funcional (sliders, autocompletes, ….). Soy de los que cree que esta responsabilidad debería caer en el maquetador, ya que es el que está más cerca del diseñador para saber que funcionamiento ha de tener esa porción de web concreta.
Por otro lado, nos encontramos con que hay ciertas funcionalidades que afectan, tanto al maquetador como al desarrollador web, por ejemplo los autocompletes (suggest), validación de formularios, … esta funcionalidad es a veces un poco difusa. En este punto entra lo que yo llamo, en alarde de originalidad POM (Programación Orientada a Maquetadores).
POM: Programación Orientada a Maquetadores
Se trata de ofrecer al maquetador una serie de herramientas que le permita añadir funcionalidad básica al HTML sin necesidad de tocar una sola línea de Javascript. Básicamente se trata de generar componentes autónomos que lean el HTML y los atributos especiales que este HTML ha de tener.
Hace ya mucho tiempo, publiqué un ejemplo de validación de formularios con jQuery que seguía esta metodología. Se basaba en indicar a cada elemento de que tipo de validación requería para comprobar los datos de entrada. A grandes rasgos, vemos que usando el class de los atributos <input />, <select />,… informábamos el tipo de validación.
Atributos data-*
Entonces llegó HTML5 y sus atributos data-*, unos atributos que abren un abanico de posibilidades, y aunque antes me daban un poco de miedo, ahora disfruto con ellos
Los atributos data-*, nos permiten dotar a nuestros elementos de un montón de datos que podemos usar en nuestro código javascript, de forma que podremos construir un código capaz de trabajar con ellos y construirse en función de ellos.
Veamos un ejemplo:
<input type="text" class="autocomplete estilobonito" data-max-items="15" data-type="clientes" data-min-length="3" />
// jQuery
$("input.autocomplete").bind(function(){
// Recogemos valores
var $this = $(this),
$value = $this.val(),
$maxitems = $this.data("max-items") || 5,
$type = $this.data("type") || "compras",
$minlength = $this.data("min-length") || 5;
/* Funcionalidad */
// Salimos si ha pulsado menos de $minlength carácteres
if ($value.length < $minlength) return;
jQuery.getJSON("http://miservicio.com/", {
type: $type,
items: $maxitems,
value: $value
},function(){
/* LO QUE QUIERAS HACER*/
});
});
Como podemos ver, nos permita acceder a ellos fácilmente, sin jQuery y para IE es igual de fácil.
¿Donde está la gracia?
La gracia está en hacer el código lo más reutilizable posible, haciendo que nos permita configurar nuestros elementos HTML de forma fácil. En mi caso personal, esta programación ha conseguido descargarme bastante de trabajo que antes hacía yo para que ahora los maquetadores/diseñadores puedan configurar.
Por experiencia, puedo decir que siempre terminas modificando el código y adaptando el código a las diferentes necesidades del diseño, pero se convierte en una tarea más sencilla y fácil de depurar.
Un ejemplo que estamos usando y que nos funciona muy bien, a ver si un día puedo implementar una versión de demo para que la veáis, es un autocomplete usando el de jQuery UI, capaz de diferenciar entre 3 o 4 tipos diferentes de datos y 3 o 4 salidas diferentes que comparten prácticamente todo el código.
Esto, añadido al modelo de programación modular que vimos hace ya muuucho tiempo, nos está dando unos muy buenos resultados, tanto a la hora de desarrollar como a la hora de depurar la aplicación.
