¿Joomla o WordPress?

Podríamos llamarla “la pregunta del millón”, por el millón de páginas web que intentan discernir cual de los dos sistemas, reyes indiscutibles de la gestión de contenidos Open Source, es el mejor. La mayoría de esas páginas concluyen en una solución de compromiso, que viene a ser algo así como “cada uno es para lo que es, Joomla para diseño web, y WordPress para blogs”.

Siendo una afirmación incontestable, creo que encierra un grave error:

• Es rigurosamente cierto a mi entender que WordPress es la mejor solución para Blogs.
• Es sin embargo falso (también a mi entender) que Joomla como editor web pueda compararse a WordPress como editor de blogs.

La razón principal no es que uno sea mejor que el otro (que también) sino algo más sutil:

• Un blog es un desarrollo más o menos estándar. Aunque haya matices, la estructura es la que es, todo el mundo la quiere similar, y pocas veces necesitas retorcer seriamente el modelo de prestaciones y navegación base del sistema. De ahí que un buen producto de gestión como WordPress sea una solución idónea.
• El diseño web sin embargo es un mundo mucho más heterogéneo, con una casuística de prestaciones y necesidades enormemente variada. Y el problema viene cuando intentas adaptar Joomla a cada caso particular. Resulta enormemente complejo alterar significativamente la estructura del CMS. Todo va rodado si te conformas con las prestaciones estándar, pero la personalización, siempre que la hemos abordado, ha sido un auténtico infierno (me refiero a la personalización de prestaciones en cliente y/o en servidor, no a la personalización gráfica, que siendo engorrosa es más o menos asequible).

Por eso, mi respuesta a la pregunta del millón sería:

• WordPress, el mejor para blogs
• Joomla, el mejor para una web que tenga precisamente las prestaciones que Joomla propone en sus módulos base o en los más testados de los módulos adicionales disponibles. Para cualquier otro caso, descártese de inmediato.

¿Framework sí o no?

Antes de analizar diferentes frameworks para desarrollo sobre tecnología web y las ventajas y desventajas de cada uno de ellos, lo primero que tal vez el programador se preguntará es ¿debo usar un framework?

Lo fácil sería responder sí o no, y dar una serie de argumentos en refuerzo de la opinión expresada. Pero eso ya lo hacen docenas de páginas, y además tanto en uno como en otro sentido, por lo que vamos a intentar dar un criterio de decisión algo diferente, en tres pasos:

• PASO 1: ¿Cuánto has programado anteriormente?
  Si la respuesta es MUCHO, salta al paso 2
  Si la respuesta es POCO / ALGO , sigue programando sin framework hasta que la respuesta sea MUCHO. En ese momento, salta al paso 2
• PASO 2: ¿Hablamos de un framework para la programación server side, o un framework para client side?
  
  En caso de framework para programación server side (JSP, PHP, .Net), salta al paso 3
  En caso de framework para programación client side (JavaScript), la respuesta es muy fácil. SÍ, USA FRAMEWORKS. Pero además no sólo uno, sino varios: Prototype, JQuery,.. facilitan enormemente la vida del programador JavaScript y le ofrecen recursos de todo tipo que tardaría una vida en desarrollar por sí mismo. Además, no comprometen la estructura del proyecto, salvo en casos muy puntuales, y tienen pocos problemas, que un día trataremos y veremos que no son graves.
• PASO 3: ¿Debo usar un framework para la programación server side?

  Por qué una respuesta tan vaga? porque cada caso es un mundo, y el de la programación de proyectos de cierto volumen (como aquellos en los que un framework puede aportar valor) no es un mundo sencillo. En algunos casos será útil, en otros no. Tú conoces tu caso. Informate y toma una decisión en base a lo que aprendas sobre los frameworks, y no en base a lo que gente como nosotros opine al respecto. Hay escritas grandes verdades, y también verdaderas tonterías tanto a favor como en contra de los frameworks.

  La respuesta es sencilla, aunque tal vez un poco frustrante. Sí, pero sólo si estabas convencido de hacerlo antes de leer este Post. Es decir, si previamente te has empapado de documentación sobre cada uno de ellos, has leido docenas de casos / experiencias / opiniones en uno y otro sentido, y finalmente has decidido que vas a usar un framework.

Accesibilidad versus usabilidad

En esta categoría vamos a tratar asuntos relacionados con usabilidad y con accesibilidad. Y qué mejor que empezar distinguiendo entre ambas. No desde un punto de vista excesivamente técnico, sino desde un punto de vista de lo que supone para una empresa o institución tener su web usable, tener su web accesible, o tenerla simultáneamente usable y accesible.

Así, la USABILIDAD supone que una web será cómoda de utilizar: fácil de navegar, rápida, clara, y dotada de recursos para facilitar la experiencia de navegación. En definitiva, algo que toda empresa e institución quiere.

Por contra, la ACCESIBILIDAD en clave de diseño web supone incluir en la web mecanismos adecuados para asegurar que aquellos colectivos con determinadas dificultades de acceso (por ejemplo, personas ciegas o con percepción limitada del contraste) puedan acceder correctamente al contenido de la página. Aunque también debería ser un objetivo común de empresas e instituciones, aquí sí hay diferencias notables: las instituciones públicas están OBLIGADAS POR LEY a cumplir estos requisitos, y las empresas no lo están, salvo aquellas de especial interés público (Renfe, bancos, operadores de servicios primarios como la luz o el agua,…).

Lo ideal sería hacer todas las webs usables y accesibles. Pero en la práctica, la accesibilidad se aplica mucho menos, y prácticamente sólo para instituciones públicas. ¿ Por qué ? porque el coste de producción del diseño web aumenta. Algunos “gurús” afirman que esto no es así, que si usas adecuadamente los estándares, la accesibilidad prácticamente ocurre por sí misma. Blablabla. No es cierto. Maquetar en accesible es más lento, más caro, y tiene todavía bastantes limitaciones respecto a una maquetación libre adaptada a estándares. Principalmente, debido a los siguientes puntos:

1. Uso de JavaScript: por definición, EN PRINCIPIO no accesible (otro día matizaremos esto, ya que este es un artículo introductorio y no ha lugar a entrar en mayor profundidad). Sin embargo, sin duda JavaScript puede aportar mucha usabilidad.
2. Uso de unidades relativas: es requisito de la accesibilidad. Sin embargo, si se asume al 100%, las posibilidades de diseño gráfico se ven limitadas, y bastante. No hay más que ver las webs institucionales que asumen esta premisa al 100% (por ejemplo, Gobierno de Aragón, Sede electrónica del Ministerio de Economía y Hacienda,..). Respetan la premisa al máximo… pero son feas de narices. ¿Cómo se le vende a una empresa que su web será más fea y más cara pero a cambio más accesible? se aceptan sugerencias.

En próximas entradas profundizaremos en estos temas.

Sistemas CMS: todos distintos, todos los mejores

Los sistemas de gestión de contenidos para sitios web, habitualmente conocidos como sistemas CMS (Content Management System), son uno más de los microuniversos que actualmente tienen cabida en Internet, y la red ofrece millones de páginas de información sobre los mismos.

Ahora bien, el problema es ELEGIR UNO. Sin ser una decisión que marque un antes y un después en tu vida, sí que tiene importancia a nivel de comunicación empresarial, ya que será la vía por la que la empresa lance al mundo su información. Esta elección tiene tres problemas fundamentales:

1. La SOBREOFERTA: hay tantos y tanta informacion sobre cada uno, que aun disponiendo de múltiples comparativas es labor sobrehumana para un profano en la materia hacer una elección realmente motivada por criterios objetivos.
2. La falta de RIGOR EN LA PUBLICIDAD: como dice el título del post, estamos de enhorabuena. Todos son los mejores. O al menos, eso afirman en sus webs y en su publicidad. Todos son sencillos de usar, todos son escalables, todos te proyectan a un nuevo escalón de libertad en la gestión de tu sitio web.
3. La necesidad de PROBAR PARA COMPROBAR: en línea con el punto anterior… ¿ y si toda esa sencillez y flexibilidad luego no son tales? un CMS en condiciones no se implanta en 10 minutos. Para cuando nos demos cuenta de que nuestra elección fue incorrecta, tal vez sea demasiado tarde y tengamos que asumir los costes de un “divorcio” traumático.

El objetivo de este hilo será el intentar arrojar un poco de luz sobre este tema.

AVISO: por muy objetivos que intentemos ser , nosotros TAMBIÉN CREEMOS TENER EL MEJOR CMS, por lo que debe aplicársenos el punto 2: tómense nuestras opiniones con cautela. Intentaremos ser claros y aportar criterios universalmente aceptables, pero siempre serán los que nosotros mismos un día asumimos como propios al diseñar nuestro producto.