Domenico Modugno – ‘O ccafè (Coffee)

La palabra Tlalnepantla es un vocablo náhuatl compuesto de 2 partículas: tlalli (tierra) y nepantla (en medio), lo cual deriva en 2 acepciones: En medio de la tierra y Tierra de en medio, siendo esta última la más popular desde el siglo XIX.

En la actualidad, conviven poco más de medio millón de habitantes y 50 ramas industriales, es uno de los municipios que más aportan al PIB nacional y estatal. Cuenta con numerosas vías de comunicación y transporte, colinda con el norte del Distrito Federal y ha hecho hermandad con 4 ciudades en el mundo, entre ellas 马鞍山, China.

Vale la pena recordar una fecha como hoy ya que, además de lo anteriormente mencionado, es el primero en la lista de los lugares favoritos no-matter-what de este autor.

¡Felicidades Tlalnepantla!

Pueden saber más de este taller acá

Así mismo, en el sitio de la Gira Telmexhub pueden comprar sus boletos para este evento que viene grande.

¡Nos vemos allá!

Pues bien, siguiendo esta metodología de utilizar “nuestras propias fuentes” así mismo deberíamos hacerlo con los colores.

La época en la que solamente se usaban los 256 colores web-safe quedó atrás hace muchos años y la amplitud en el espectro hexadecimal/rgb nos permite utilizar unos 16’777,216 colores, los cuales utilizamos desde las propuestas en PSD hasta la maquetación final con HTML y CSS

Pero qué hay a la hora de construir el CSS que utilizaremos ¿de qué forma memorizamos el hexadecimal o el RGB para cierto tipo de rojo, verde o azul? Existen software que puede hacer esta labor por nosotros o metodologías de conversión con Javascript o para los más aventados, usar lenguaje de servidor para procesar el CSS con variables.

¿Tan complicado es?

Es por esto que la propuesta de @palette queda formalmente establecida aquí

Usando @palette

La definición quedaría de esta forma

{code type=”css”}

@palette {
red: #CA000;
jeans: #1288AB;
[custom color]: <hex | rgb value>
}

{/code}

Y declarando en las reglas de CSS normalmente

{code type=”css”}

.clase {

color: jeans;

}

#id {

background: red;

}

{/code}

Explicación

En @font-face podemos redeclarar una tipografía o bien declarar una nueva para usarla normalmente en el resto del CSS

En @palette estaríamos haciendo prácticamente lo mismo pero con colores, de esta forma, tenemos nuestra paleta de colores declarada y reemplazamos hexadecimales o rgb’s por nombres de fácil lectura e identificación.

En este taller está dirigido a programadores y diseñadores principalmente, con un espacio para publicadores.

Es un taller intensivo de 2 horas donde se tratarán los siguientes temas:

• Estructura adecuada de contenidos
• Advanced theme authoring
• Creación de plugins orientados a administración y publicación
• $wpdb, filtros y acciones.

Requisitos del taller:

• Interacción previa con WordPress en publicación
• Haber curioseado un theme (modificado o creado)
• Instancias necesarias para trabajar (localhost instalado o servidor remoto)

Este taller ya se encuentra publicado en la agenda general de Campus Party y está disponible para reservarse en tu panel de campusero.

¡Asiste!

En la mesa redonda compartiremos espacio Guillermo Rivero, David Hernández, Sergio Fajardo y un servidor, en el cual debatiremos sobre desarrollo, integración en grandes proyectos, mercado y otros más, en relación a CMS.

Este evento ya se encuentra publicado en la agenda general de Campus Party y está disponible para reservarse en tu panel de campusero.

Nos vemos allá.

Contenidos:

• Theming desde la base
• Plugins, cómo implementar y cuándo hacer

Niveles:

• WordPress: Básico
• PHP: Básico, intermedio

Nota importante:

El asistente podrá llevar bolígrafo y papel JFTL. En caso de querer practicar en vivo, debe tener ya todo listo con un servidor remoto PHP5 & MySQL5 o bien, localhost en su equipo, no es complicado, hay muchas formas de hacerlo en 5 minutos.

¡Nos vemos mañana!

En ocasiones, el mar de ego es grande, tan grande que algunos se ahogan y predican por doquier que el usuario no tiene el suficiente IQ para entender las avanzadas funcionalidades de un sistema que en realidad, no está hecho para ser usado.

¿Quién tiene la culpa en realidad?

No se trata de encontrar culpables, solamente de equilibrar responsabilidades al momento de realizar un sistema. Dichas responsabilidades se administran en la planeación de un producto.

Planeación y perfiles

No se hablará sobre tiempos y costos que, aunque son importantes, son tan sólo el comienzo de un proyecto. Aquí se trata de perfiles en ambas partes, tanto productor como consumidor; de no considerar perfiles, lo más probable es que un proyecto se termine, pero no llegue más allá de los 3 meses.

Del lado del productor, se deben considerar perfiles de realización de producto. Debe quedar en claro que no tiene la misma forma de pensar un programador que un vendedor, ¡y eso está bien! así mismo, existen perfiles de visión amplia que son capaces de entender más de 4 aspectos en la creación de un producto y sirven como conectores o facilitadores en la PODC de un proyecto.

“Pero, pero… sólo soy yo, 1 persona, estoy solo en el mundo” Sí sí, en ocasiones el reducido presupuesto hace que 1 sola persona tenga que hacer todo, dado que un dream team o ejército de la salvación del mundo, saldría demasiado caro. Basta con considerar 2 cosas: calcular el costo de no permanecer en tu mercado objetivo o bien, solicitar ayuda a un usuario, igualito a quien usará tu producto.

Funcionalidades versus usabilidad

Sin importar el tipo de sistema, ya sea de consulta o gestión, puede venir equipado con procesos tan avanzados que pueden mejorar para siempre la vida de quien lo use.

No se trata de qué hace, se trata de cómo se hace, si en el cómo no se factoriza al mínimo el qué, de nada sirve que existan toneladas de código si al final, cuesta trabajo enviar un simple correo.

¿Instructivo? algunos los leemos… pero en casos extremos

Siempre es bueno tener a la mano un instructivo claro y entendible que nos explique algún detalle avanzado sobre el producto que estamos usando. ¡Detalle avanzado!, más no recurrir a él cada vez que queremos escribir nuestro nombre en un simple campo de texto y el fantástico mensaje es “Error, corrija los campos” o no decir absolutamente nada y esperar a que el usuario crea que algo está haciendo mal cuando en realidad, lo mal hecho está del otro lado.

Funciona perfecto ¿y cuando no funciona?

El humano hace productos y tal parece herencia: todos los humanos tienen errores y por consiguiente, lo que el humano haga en algún momento tendrá errores (si no los tiene, que surja la preocupación, porque algo anda mal). No es trabajo del usuario encontrar dichos errores, el usuario llega literalmente a usar un producto, no llega a arreglar ni a avisarle a quien lo pueda arreglar, esto debe quedar claro; por el contrario, el usuario encuentra un error, se lo dice a otro usuario y viene una reacción en cadena tal, que el último en enterarse es el programador (después de haber pasado por dirección).

Sobre el manejo de fallos

En verdad, a nadie le importa el código de error 0988u54 o el fallo del puerto SystemOccupiedManyNumbers, incluso a los propios programadores comienza a ser confuso el manejo de estos errores cuando reciben los reportes de usuarios que, además de molestos, están confundidos porque creen que algo hicieron mal. Lo anterior es juego de niños, posteriormente esto se traduce en números y en pérdida de clientes, este tipo de fallos deja en claro que el producto no está hecho para el consumidor final, sino para un selecto grupo que entiende lo que esos jeroglíficos significan… cuando sabemos que es al revés.

Además, dejar un mensaje del tipo: “Avísale al administrador del sistema” ¿qué significa, que además del tiempo que se está perdiendo con el ErrorMuchosNúmeros, todavía hay que “avisarle a alguien” para que lo corrija? mal, muy mal.

Tan sencillo como programar una simple rutina de aviso de error, colocar un mensaje humanamente entendible (jocoso incluso) y establecer un puente de contacto con el consumidor para que se le avise que lo que le impedía usar el robusto sistema ¡fue arreglado!

Es momento de la carita feliz

No todo es malo en el mundo, el presente ensayo no es un regaño, hay suficiente tiempo como para hacer los ajustes necesarios. Sin importar el perfil de quien esté encargado de la programación del sistema, basta con saber un poco de álgebra y factorizar los elementos de error en 1 sólo, que en realidad sirva.

Se debe recordar que un mensaje de error es una excelente oportunidad para que el usuario deje de ser un cliente o bien, para crear lealtad con el usuario… ¿Cómo? es cuestión de cómo se maneje la situación. Si cuesta trabajo realizar ésta conversión, tal vez la respuesta no la tenga el usuario, sino mercadotecnia.

En el software, es común tener documentado el código que realizas, con el objetivo de que sirva como futura referencia personal o colaborativa en el caso de que haya más personas colaborando en el mismo archivo o proyecto.

Esto ocurre en el caso de lenguajes de programación, donde cada función, variable, clase, procedimiento, método, interface, etc., cuenta con unas líneas donde se explica el comportamiento del elemento anteriormente mencionado.

En el lenguaje de marcado como HTML, también suelen realizarse anotaciones antes y después de los bloques que encierran información, sobre todo cuando se prepara el archivo para incorporarse a un sistema de plantillas donde habrá que separar 1 archivo HTML en otros 4 o 5 y no perder el control de qué fue lo que se copió.

Para documentar el código se utilizan los siguientes delimitadores para encerrar dichos comentarios, de acuerdo al lenguaje de programación/marcado que estemos utilizando: /* */, #, <!– –>, ”’, #FRASE, etc.

¿Qué ocurre con CSS?

Resulta que, existe un lenguaje de estilos en cascada o CSS que se ocupa principalmente en páginas Web (sí, páginas, no importa si son portales, sitios de presencia o grandes monstruos, a final de cuentas envían una página en HTML) y que, también se utiliza en algunas interfaces de sistemas operativos, como es el caso del explorador del ya casi descontinuado Windows XP.

Centrándonos en Web, una hoja de estilos reúne el cómo vamos a presentar la información, con qué apariencia y distribución.

Si es un archivo pequeño (200 líneas) fácilmente podremos identificar qué es lo que hace cada selector y ubicar qué parte vamos a cambiar. Pero qué ocurre cuando hay circunstancias donde son más de 500 líneas o bien, hay n cantidad de selectores y zonas con non-CSS-framework aplicado, cosas bonitas pues. ¡Problema!

Para estas situaciones, coloco 2 ejemplos, uno con el problema y otro con la solución, más abajo daré la explicación.

Problema:

Solución

¿Qué patrones seguir para esto? Propongo utilizar el siguiente patrón:

En CSS se documenta utilizando el siguiente estilo /* */, por lo que, no importa el número de cosas que existan después del primer /* lo que siga estará comentado o fuera de interpretación hasta que aparezca el cierre de comentario */

Entonces, ¿por qué no usar el número de * para indicar configuraciones, páginas o secciones dentro de páginas, sobre todo porque ya viene <section>.

/***

Para indicar configuraciones globales, tales como resets, adaptaciones globales de tipografía y estilos de etiquetas por clases

/**

Para indicar el comienzo de reglas de una página en específico, sin importar si esta página hace relación a un artículo individual, portada con múltiples elementos o secciones con múltiplces posts

/*

Para indicar la sección de una página.

Pero aquí no termina todo, no vamos a ir por la vida haciendo búsquedas mentales usando expresiones regulares en nuestros CSS’s, por lo que, usaremos los siguientes identificadores, posteriores al indicador de comienzo de comentario. ¡Agreguemos semántica! (o cuando menos seamos claros en lo que queremos hacer)

@reset:

Con el tipo de reset que se aplicó, solamente hará basta con identificar si fue completo y qué técnica se utilizó o bien, si fue parcial o fue tipo *. Por ejemplo:

/*** @reset: yahoo */

/*** @reset: meyer */

/*** @reset: partial */

/*** @reset: wildcard */

@settings:

Con el tipo de configuración que vamos a aplicar: globales, sólo en ciertas páginas o, alguna adaptación derivada de usar AJAX en nuestro sitio, etc.

/*** @settings: globals */

/*** @settings: ajax-classes */

/*** @settings: relatives/absolutes */

@page

Esta es una de las más importantes, se coloca cada que utilizamos CSS específico para una página, se coloca el nombre/identificador de esta.

/** @page: home */

/** @page: news */

/** @page: contact */

/** @page: faq */

@section

Otra de las más importantes, dado que es para indicar el comienzo de una zona en específico dentro de la página, es decir, una sección de html, tal como una galería o un slider.

/* @section: galería */

/* @section: slider */

/* @section: formulario */

@plugin

Esta última solamente se implementa cuando se utiliza un plugin externo, usualmente de jQuery u otra librería de Javascript o bien, algún “plugin” de CSS que se nos ocurra en un principio o incluso, el CSS que utilice un plugin de un lenguaje de servidor en específico.

/* @plugin: jquery.qtip */

/* @plugin: jquery.easyslider */

/* @plugin: wp-contact-form-7 */

Nota importante: solamente se marca el comienzo de la zona de CSS, no se marca el final, el final de la zona que se está realizando

Utilidad

Cualquier software de documentación puede parsear fácilmente el CSS y hace runa búsqueda por los 3 tipos de limitadores /***, /** y /* e identificar qué tipo de sección dentro de nuestro CSS existe: @reset, @settings, @page, @section y @plugin. El objetivo es que se pueda brincar de una sección a otra dentro de nuestro CSS, sin tener que hacer scroll buscando o recordar la línea desde donde comienza la utilidad de nuestro CSS.

Únete

Como lo comenté al principio, este es un borrador que contiene una propuesta para documentar los archivos CSS que realizamos de una forma estándar, organizada y entendible. No hay nada mejor que concretar y nutrir una idea que puede server a miles de personas. Eres libre de comentar y aportar el conocimiento necesario a este borrador  para que se concrete.

Divulga este artículo para que más personas involucradas con CSS conozcan la propuesta http://bit.ly/CSSdoc

La causalidad es una ley, la vivimos todo el tiempo, A y B en relación y disputa interminable.

Colmar de bendiciones sin acciones no tiene sentido, así como solamente desear; una vez que se decide un destino éste se forja para que se realice como lo deseamos.

En mi artículo de ayer lo comenté, “los caminos se construyen”.

Los 3 párrafos anteriores no son ideas desordenadas, cada uno corresponde a una inexplicable razón y analogía de la postal de año nuevo que realicé con un objetivo, el transmitir que sin importar la temporalidad, todo es un resultado, obra y realización de factores completamente manipulables y de amplio rango de oportunidad.