Hay una cosa que odio: mezclar bloques de PHP con bloques de HTML. Será que CakePHP me ha mal acostumbrado a tener separadas las vistas de la lógica, pero de verdad me molesta código que se ve así (tomado del tema default de WordPress):

No se a ustedes, pero a mí tanto <? ?> me marea y luego se me hace muy dificil entender donde empieza y donde termina un bloque. Desgraciadamente éste tipo de programación es muy común en el mundo de WordPress, algunos pupulares temas y plugins son verdaderos spaghettis indescifrables, y esto es en cierta manera porque asi es la manera en que WP está escrito.

CakePHP, por otra parte, tiene una solución interesante para este problema (en realidad, creo que es una solución para un problema distinto, pero denme chance) en la forma del HTMLHelper, pero para tags complicados y con muchos atributos, el código se vuelve demasiado y a mi siempre me cuesta recordar el orden de los parametros.

Cuando decidí aventarme a crear temas premium para WP, una solución para éste problema fue una de las principales razones para escribir el Duperrific Theme Engine de donde finalmente extraigo lo que ahora les presento como CSML.

Ejemplo:

Como verás csml::tag() toma un selector como parametro y regresa un tag de HTML, mientras que csml::entag() toma una cadena y la envuelve con el selector designado en el segundo parametro. En el caso de csml::entag() el segundo parametro tambien puede ser un array de selectores, lo que hará que anide los selectores uno dentro de otro, empezando por el último selector del array.

Aunque la forma más facil de utilizar csml, es usando las dos funciones incluídas: t() y en() que son wrappers para csml::tag() y csml::entag() respectivamente y además imprimen el tag.

Un ejemplo más de la vida real:

Apenas estoy empezando en esto de liberar cosas que he hecho, así que espero que les resulte tan útil como a mí me ha resultado. Si la usan me avisan y si encuentran algún bug me dicen o, mejor aún, forkean el proyecto y lo arreglan.

La primera cosa que noté en los temas que se venden como premium en el mercado es al parecer su enfoque es muy estrecho. Pareciera que su único objetivo es verse muy bien y ser muy atractivo para el usuario final o lector del sitio y dejan de lado a los otros roles que intervienen en un sitio web: desarrolladores, diseñadores y editores o colaboradores, dándoles poca o ninguna importancia.

Con esto en mente me puse una serie de reglas o lineamientos que tenía que seguir a la hora de desarrollar mis temas, con la premisa de que no liberaría nada hasta que pudiera satisfacer todas ellas. Este es el Duperrific Manifesto:

1. La usabilidad es primero, la apariencia viene después. Antes de comenzar hay que tener nuestras prioridades en su lugar.


2. Ofrecer soluciones completas y en paquete. Mi cliente no tiene porque buscar entre miles de plugins para ver cual satisface sus necesidades, todo lo que necesita viene empaquetado en su descarga.


3. Ofrecer un verdadero framework de desarrollo. Donde al igual que en todos los frameworks que se respetan: “Convención sobre configuración” es la frase clave.


4. Escribir código extensible y reutilizable. ¿Por qué repetir código?


5. Programar Orientado a Objetos. Tanto como WP, que es casi completamente funcional lo permita.


6. Los temas deben ser absoloutamente flexibles. Los widgets, son una poderosa característica que WordPress trae de fábrica y que aún no se ha aprovechado cual debe ser.


7. Configurar el sitio debe ser sencillo.  El diseñador no tiene por que editar una línea de código. WP nos permite añadir nuevos paneles de control a la administración del sitio, démosle buen uso.


8. Crear contenido debe ser simple. Por lo tanto, las funcionalidades avanzadas de nuestros temas deben ser abstraídas. Los editores no tienen por que saber qué es un campo personalizado para meterle una foto a un artículo.

Estuve meditando mucho al respecto, estudiando las propuestas del mercado y comparándolas con necesidades reales que me he topado en estos 5 años que llevo desarrollando para la web y estas son mis conclusiones.

Las Necesidades de Los Diferentes Roles Usuario

Personalmente, identifiqué 4 roles que tienen parte en un sitio powered by wp y deben ser tomados en cuenta: El Programador, El Diseñador, El Editor y El Usuario Final. Nótese que hablo de roles y no de personas puesto que a menudo una sola persona desempeña más de un papel o es un equipo completo el que se dedica a cierta tarea.

El Programador es el que entiende bien –o más o menos bien– el código que hace funcionar a WordPress y realiza temas o plugins que se adapten a las necesidades de su cliente o de su usuario final.

Los mejores programadores se preocupan por un código limpio, ordenado y bien documentado y están dispuestos a seguir convenciones que refuercen la limpieza y confiabilidad, así como la reusabilidad de su código.

Por alguna razón ésta no parece ser una cultura extendida en el mundo de WordPress y una gran mayoría de los temas y plugins existentes parecen más que fueron hackeados al paso que desarrollados con los estándares arriba descritos. Quizá solo sea que despues de pasar mucho tiempo en los mundos de CakePHP, jQuery, RoR y Cappuccino me volví quisquilloso.

Al Diseñador le toca la parte que se ve y la que le da la cara al usuario final. Aunque para que un diseñador web sea más completo es bueno que sepa HTML, CSS y hasta PHP o JavaScript estas deben ser entendidas como habilidades accesorias o plus pero que no forman parte del quehacer propio de un diseñador.

Idealmente el diseñador debería estar preocupado por el branding, por la legibilidad, por comunicar y resolver problemas gráficamente y debería poder lograrlo de forma intuitiva y gráfica sin necesidad de andar desenredando loops anidados.

Desgraciadamente poco desarrolladores de temas para WP toman en cuenta al diseñador de a pie y hacen que implementar un diseño a partir de un tema sea una labor tediosa y estresante.

Para El Editor, que es la persona encargada de meterle el contenido al sitio las cosas están fáciles si el sitio se trata de un blog convencional porque, seamos sinceros, para eso fue diseñado WordPress. Si queremos algo más, así sea una modificación tan cercana como una revista electrónica en lugar de un blog entonces las cosas comienzan a ponerse feas.

Imaginate explicarle al editor que en ocasiones un post no es un post sino que puede ser un producto o una fotografía depende de en que categoría lo coloque. Que a veces el campo “excerpt” es para poner un teaser del post pero en otras ocasiones se trata del pie de página de una foto. Que por cierto la foto debes recortarla en 3 diferentes tamaños y luego subirla, copiar la url y pegarla en un custom field que debe llevar un nombre determinado.

Y para el Usuario Final o lector o cómo uno quiera llamarle, todo debe ser transparente y fácil de usar. Hace poco escuchaba una entrevista con Irene Rosenfeld, CEO de Kraft Foods donde decía que al vender comida el factor decisivo es que ésta tenga buen sabor.

Con los sitios web sucede algo parecido, el factor decisivo es que al usuario final le sea útil, sin este factor, lo demás no sirve de nada.

Resolviendo Necesidades

En los últimos dos meses he estado experimentando y probando diferentes maneras de resolver los problemas que he planteado en éste post y me siento confiado en que encontré la mejor manera de resolverlas.

En una siguiente entrefa les platicaré mi approach y como estoy resolviendo estos problemas en mi propia linea de premium themes que voy a lanzar muy, muy pronto

Si piensan que estoy completamente equivocado, ya saben “cómo decirmelo”#respond