Sopa de bits » Blog » Del gestor de contenidos al gestor de publicaciones (II)
27
ene 2009

Del gestor de contenidos al gestor de publicaciones (II)

Caracterizar o etiquetar los tipos de publicaciones


La flexibilidad de la difusión es el factor que más puede determinar las capacidades de un PMS así. Es fácil dejarse llevar por definiciones generales sobre los tipos de publicaciones. Pero es difícil que eso concuerde con una realidad (especialmente en el canal on-line), porque cada caso es distinto y la personalización está en el orden del día.

Aunque los parámetros que configuran una publicación se repiten en muchos casos, a veces pueden ser imprescindibles y en otros superfluos, y que unas pequeñas variaciones sobre estos parámetros configuran una publicación totalmente diferente.

Al analizar el desarrollo de una aplicación así, podemos tomar la realidad que conocemos y utilizar "tipos" de publicaciones, o bien desglosar estos "tipos", detectar sus parámetros y analizar cómo pueden variar.

La primera alternativa tiene la ventaja de ser más rápida de conseguir (ergo más barata si hay que desarrollar una aplicación), y el inconveniente que puede conducir a una solución rígida y poco adaptable a los cambios. La segunda alternativa tiene un punto de partida más complejo, corre el riesgo de obviar alguna característica importante, y de no ser exhaustivo, pero a su vez permite mejorar la flexibilidad del resultado final.

No hay solución única, depende de cada caso. Yo escojo la segunda.

Parámetros básicos


Observando los ejemplos que corren por donde he llegado, y combinando esto con los casos que he vivido de cerca, creo que hay una lista de parámetros clave. No pretende ser una lista exhaustiva, pero sí significativa en la mayoría de casos.

  • Respecto al sistema de empaquetado:
    • Sin empaquetado. Los contenidos van por libre en un listado continuo.
    • Empaquetado de portada/resumen, con acceso al detalle o listado de contenidos no encapsulados (archivo de contenidos).
    • Empaquetado por entrega (issue).
  • Quién establece el criterio de selección
    • Decisión editorial/interna.
    • Personalización del usuario.
    • Combinación de ambas.
  • Cómo se establece el criterio de selección
    • Línea editorial
    • Temática
    • Filtros por otros campos (autoría, coincidencia full-text, etc)
  • Periodicidad de actualización
    • Flujo continuo: en cuanto el contenido está disponible se difunde (a modo de stream)
    • Cronológica (cada X horas/días/semanas/meses...)
    • Según el volumen (cuando al menos hay X contenidos disponibles).
    • Sin periodicidad: Sitios estáticos que no actualizan sus contenidos.
  • Niveles de acceso (cada nivel debe combinarse con un criterio de control de acceso):
    • Publicación general / portada.
    • Sección / Apartado / Temática.
    • Detalle del contenido.
    • Archivo/hemeroteca de contenidos antiguos.
  • Criterios de control de acceso (deben combinarse con los niveles de acceso):
    • Totalmente abierto (usuarios anónimo).
    • Restricción de acceso por cuentas de usuario.
    • Restricción de acceso por perfiles de usuario.
    • Restricción por caducidad (suscripciones gratuitas o de pago)
    • Restricción por pago (pay per view)
  • Organización de los contenidos:
    • Líneas editoriales / Secciones.
    • Formatos o tipos de contenidos.
    • Temática (categorías, etiquetas, etc).
    • Otros elementos y campos (fuente, autoría, coincidencia full-text, etc)
  • Canal de difusión/distribución:
    • HTTP (Web,RSS,etc): visualización en el navegador o similar.
    • e-mail: visualización en el cliente de correo.
    • SOAP/XMLRPC (visualización determinada por el solicitante)
    • Impresión.
    • Otros (La lista puede ser muy larga)
  • Formato:
    • HTML
    • RSS (+HTML)
    • PDF u otros formatos binarios
    • Impreso
  • Destinatarios (target):
    • Usuarios visitantes (difusión pasiva).
    • Suscriptores aceptados.
    • Clientes potenciales (con o sin filtro de segmentación)
  • Análisis de la interacción:
    • Ningún análisis (al raro hoy en día).
    • Análisis básico: Uso de variables básicas como páginas vistas, Visitas, Usuarios únicos, tasas de rebote...
    • Análisis por segmentos: Combinación de variables básicas para identificar tipologías de usuarios.
    • Objetivos de navegación: Visita a una página determinada sin necesidad de realizar acciones adicionales.
    • Objetivos por acciones: Alta de suscripción, respuesta a encuestas, rellenado de un formulario, compra de producto...
  • Posibilidad de personalización:
    • Ninguna personalización.
    • Personalización general basada en contenidos, líneas editoriales, temáticas u otra información del sistema.
    • Segmentación general por grupos de personas.
    • Personalización sin datos históricos por usuario.
    • Personalización con datos históricos del usuario (tasas de impacto en difusiones anteriores).

Repasando los aspectos más habituales de lo que me he encontrado en distintos sitios, y también en proyectos en los que he trabajado, creo que las características anteriores forman el núcleo de parámetros necesarios para configurar casi cualquier tipo de publicación.

Tomando como base esta aproximación, una publicación se crea a partir de la combinación de características anteriores (y otras que no estén aquí). El nombre que recibe al final es una simple anécdota.

No todos los factores pueden combinarse de forma indiscriminada. Por ejemplo, es complejo (y seguramente nada cómodo) utilizar el control de acceso por suscripciones si el formato de difusión es RSS. Al establecer los parámetros básicos lo que se permite es que la configuración sea flexible, tras lo cual hay que establecer restricciones para casos concretos como el del ejemplo.

Otros aspectos

Hay aspectos que no considero críticos en la configuración de una publicación pero que son importantes en el resultado final.

Por ejemplo, he descartado la posibilidad de analizar los criterios de diseño y maquetación de una publicación. En este caso, lo más habitual es trabajar sobre una plantilla general que se desglosa en cajas.

Sobre este punto creo que para tener una base sólida, la aplicación debe diferenciar el aspecto visual en vistas (por utilizar la terminología del MVC ). Este detalle y la decisión sobre qué campos mostrar en cada nivel de la publicación deben depender de la gestión de vistas, y no del control interno. Evidentemente determinan el resultado final de la publicación, pero no configuran la publicación como bloque de trabajo.

Además puede ser interés trabajar con diferentes vistas para una misma publicación (un caso típico son los themes que tienen aplicaciones como Wordpress o Joomla), o introducir vistas predeterminadas que luego sean configurables (algo por ejemplo disponible en Drupal, donde es posible cambiar los colores principales en los temas que lo permiten).

Otros aspectos que hay que tener en cuenta en el nivel de la vista es la posibilidad de incrustar widgets y otras cajas con contenidos/servicios externos (si el objetivo implica un mashup). El caso más obvio es el de la publicidad. No debería ser necesario generar un tipo de contenido "banner" teniendo opciones libres como OpenX , o bien opciones conocidas como AdSense. También sería interesante pintar datos utilizando gráficos estadísticos que dependan de aplicaciones externas.

Comentarios

01/03/2009 12:35:41 por Ani López

Fascinantes dos artículos. si señor.

01/03/2009 18:55:59 por Mario

Gracias ;-). Quizá un pelín teóricos. Confío poder dedicarle un poco de tiempo para entrar más a fondo en estos detalles.

02/03/2009 12:43:18 por Ani Lopez

como un servidor se ha dedicado unos 9 años a construir CMSs y SEO friendly CMSs cualquier cosa que sea ir más allá me parece de lo interesante. Permaneceremos atentos a tu pantalla :)
Saludos

Escribe tu comentario

Nombre   
Comenta Escribe la séptima palabra que aparece en la lista siguiente:

trabajar, difícil, con, creo, puede, stream, general, tipos, usuario, acceso

Palabra: