La nueva web de la Universidad Católica

Hoy la Universidad Católica, a la que tengo el honor de pertenecer como alumno (tranquilos, es sólo peloteo en época de exámenes) ha lanzado la nueva version de su web. Un nuevo diseño y unas nuevas tripas, basadas en Plone. Conozco el equipo que está detrás del proyecto (yo mismo estuve involucrado en sus comienzos), el talento que se ha derrochado y la gran cantidad de horas que se han invertido. Desde hace dos años, el Servicio de Actividades Web ha infundido esperanza y ganas de trabajar en un cambio radical para la estructura comunicativa más importante de la Universidad.

Me quito el sombrero ante la transformación que se ha ejercido en la cultura de una empresa como la UCAM y el esfuerzo que ha significado pasar de una cutre y asquerosa página web en HTML estático, sin ninguna estructuración del contenido, sin orden ni diseño… a un diseño bonito, una descentralización de la gestión de los contenidos (vamos, que ahora todos los empleados podrán gestionar su parcela del portal) y una plataforma técnica que puede aguantar tanto la oferta (estructuras de contenido bien diseñadas, jerarquía de los usuarios) y la demanda (información actulizada, interacciones útiles, etc). Y lo que es quizá más importante: se ha pasado de un equipo sin formación específica en desarrollo web ni habilidades comunicativas, a uno suficientemente preparado y lleno de entusiasmo.

Desde este humilde púlpito, mi más sincera felicitación a Samu, Piti, Marco, Lola, Vito, Andrés, Óscar, Víctor y un interminable etcétera de gente con ganas de trabajar por un cambio que ya se está empezando a notar en la Universidad.

Y ahora, las críticas, ¿o creías que no llegarían? ;-) Me fijaré en el aspecto técnico y de diseño de la nueva web. De todo lo demás, hay poco hay criticable (si acaso que se comunicase a la comunidad universitaria el cambio, habilitar tutoriales que mostrasen las nuevas posibilidades y un canal de feedback).

Empecemos por el principio: entrando en www.ucam.edu nos encontramos con un diseño suave y vivo con demasiado color azul (en cantidad y variedad). Para mi gusto, el fondo azul de la cabecera se estira más de lo deseable, es más, la altura a la que termina no está alineada con ningún elemento del contenido… vamos, que no hay ninguna razón para que esté ahí. En el área de búsqueda (arriba a la izquierda), los elementos están desordenados: el CSS cross-browser ha dado muchos problemas.

Ni el XHTML ni el CSS son válidos, la maquetación principal se basa en tablas y el CSS es realmente confuso (código espagueti en toda regla): definiciones redundantes, mal uso de la herencia, nula organización del código, sintaxis irregular… y lo mismo se podría decir del XHTML. Si quieres comprobarlo, desactiva el CSS en tu navegador y verás como la página se hace infumable. O prueba también desde el móvil.

Más allá del diseño, el principal error que se ha cometido es la no retrocompatibilidad del sitio, sobre todo en cuanto a URL y que faltan muchos contenidos por migrar. Ya que las direcciones han cambiado, muchos servicios dejarán de funcionar (por ejemplo, el calendario del campus virtual apunta a dirección que ya no existe), y por supuesto el posicionamiento en los buscadores bajará considerablemente. Esto tiene varias soluciones posibles, en mi opinión la más sencilla es utilizar la re-escritura de URL en un proxy web (que de hecho ya tienen para caché), de dos maneras posibles: manteniendo la antigua web bajo un subdominio diferente, y redireccionar todas las URLs antiguas al servidor antiguo; o bien redireccionar las antiguas URL a las correspondientes en el nuevo servidor (claro que eso exigiría tener todos los contenidos migrados). Ah, y en ambos casos añadir la correspondiente cabecera 301 para que los buscadores sepan que las URL están obsoletas.

Sobre la migración de los contenidos, si no ha sido realizada automáticamente, no se explica que se mantengan viejas URL, páginas mal maquetadas, datos incoherentes, información repetida, etc. Un buen ejemplo en la sección de extensión universitaria. Está claro que en cuanto a contenidos, hay mucha tela que cortar. A una marabunta de empleados y deptartamentos subiendo y migrando contenidos tiene que enfrentarse un gabinete de gestión de contenidos que esté domine las áreas de accesibilidad, usabilidad, comunicación, redacción para web, etc.

Y sobre Plone, poco que decir: es un CMS basado en Zope y CMF. En mi opinión, es el gestor de contenidos perfecto para un portal web tan grande y ambicioso como este. Es suficientemente robusto y flexible como para que el día de mañana los servicios de aprendizaje on-line e intranet estén integrados en esta plataforma. También puede sincronizarse con las bases de datos de usuarios que ya tiene la universidad. Además, su arquitectura y la de su base de datos orientada a objetos es perfecta para adoptar metodologías y tecnologías semánticas.

Una vez más, mi felicitación para los artífices de esta ambiciosa obra. Ojalá pudiera volver a colaborar con vosotros.

El operador # y su potencial olvidado

El carácter # se añade al final de una URL para indicar un fragmento o ancla en una página web. Así lo deja caer el RFC 1738 (página 2), la especificación oficial del protocolo URL:

The character “#” is unsafe and should always be encoded because it is used in World Wide Web and in other systems to delimit a URL from a fragment/anchor identifier that might follow it.

Esta es la referencia más clara al operador # que se hace en el documento, y, como se puede ver, no especifica cuál ni cómo debe ser el uso del operador, sino que simplemente nombra el uso que se le está dando, ya que el párrafo explica la codificación de caracteres.

Si buscamos información en fuentes no tan “oficiosas”, la Wikipedia nos dice que una URL tiene la siguiente estructura:

esquema://autoridad/ruta?consulta#fragmento

El fragmento identifica a una porción de un recurso, habitualmente una ubicación en un documento.

Nada nuevo de momento. Pero la enciclopedia colaborativa añade:

La parte #enlace, por último, es conocida como identificador de fragmento y se refiere a ciertos lugares significativos dentro de una página; por ejemplo, esta página tiene enlaces internos hacia cada cabecera de sección a la cual se puede dirigir usando el ID de fragmento. Esto es relevante cuando un URL de una página ya cargada en un navegador permite saltar a cierto punto en una página extensa.

Y también interesante:

Dado que el protocolo HTTP permite que un servidor responda a una solicitud redireccionando el navegador web a un URL diferente, muchos servidores adicionalmente permiten a los usuarios omitir ciertas partes del URL, tales como la parte “www.”, o el carácter numeral (“#”) de rastreo si el recurso en cuestión es un directorio. Sin embargo, estas omisiones técnicamente constituyen un URL diferente, de modo que el navegador web no puede hacer estos ajustes, y tiene que confiar en que el servidor responderá con una redirección. Es posible para un servidor web (pero debido a una extraña tradición) ofrecer dos páginas diferentes para URL que difieren únicamente en un carácter “#”.

En conclusión, el uso del operador # no está regulado ni normalizado, y es un estándar de facto únicamente en el protocolo HTTP, donde se le da un uso concreto: saltar a un marcador dentro de la propia página. Para ello está la etiqueta HTML

<a name="nombre_marcador"></a>

, aunque el comportamiento se implementa en el navegador, por lo que no es obligatoria otra llamada al servidor. No obstante, los servidores web pueden modificar ligeramente su comportamiento.

Hackeando el operador en AJAX

Hasta hace poco, éste era todo el uso que se le daba al marginado operador #: saltar a otros “marcadores” internos dentro de una página web. Hoy en día, el operador # se utiliza en combinación con JavaScript en interfaces web basadas en AJAX, donde en una sóla página (es decir, sin cambiar la parte esquema://autoridad/ruta?consulta de la URL) se producen múltiples acciones. Y se utiliza precisamente para cambiar la URL aunque el navegador realmente no recarge la página entera, consiguiente así dos interesantes detalles relacionados con la usabilidad:

  • La posibilidad de usar las funciones “Atrás” y “Adelante” del navegador.
  • La posibilidad de identificar inequívocamente una sección de la página y poder enlazarla o guardarla como favorita.

Hoy en día este comportamiento se puede comprobar en sitios como GMail o Facebook. Por ejemplo, si entramos en

http://www.facebook.com/home.php

, tenemos la página principal. Si queremos subir un vídeo, pulsamos el enlace correspondiente, el cual cargará la interfaz a través de AJAX. Si quisiéramos enviarle a un amigo la dirección para subir vídeos en Facebook, tendríamos que indicarle que fuese a

http://www.facebook.com/home.php

y, una vez allí, pulsar en “Subir vídeo”. Gracias al operador #, no es necesario, ya que el enlace que pulsamos “Subir vídeo”, además de contener un atributo onclick que cargue la interfaz de subida de vídeos a través de AJAX, es un enlace que apunta al marcador

#/video/?upload

, obteniendo así la URL

http://www.facebook.com/home.php#/video/?upload

sin haber prescindido de AJAX ni haber recargado al completo la página.

¿Hay vida más allá de HTML? I have a dream…

Como ya se ha indicado, el uso del operador # en las URL se reduce prácticamente a HTML. Y es lógico, ya que su uso no está normalizado y su utilidad en HTML es bastante reducida. En una web pensada para una lectura natural (humana), saltar a diferentes partes de la página nos puede resultar cómodo, pero no es muy útil desde el punto de vista puramente tecnológico.

Más allá de esta aplicación, las tecnologías semánticas, concretamente RDF, hacen uso extensivo de las URL (mejor, dicho de las URI) y del operador #. Un ejemplo es este encabezado RDF en el que se especifican los espacios de nombres XML que se van a usar en la descripción:

<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:cd="http://www.recshop.fake/cd#">

En este caso, el operador # no especifica ningún fragmento o ancla en los documentos referenciados. ¿Qué diferencia hay entre usarlo y no usarlo? Si probamos ambas opciones obteniendo por HTTP el documento (navegadores, wget, etc) el resultado es el mismo. Lo mismo ocurre con

http://johnbreslin.com/blog/index.php?sioc_type=site#weblog

, otra URL de ejemplo. Está claro que, a nivel de navegador no se está haciendo ninguna modificación del documento solicitado, como cambría imaginarse en un contexto de XML.

Pensémoslo. Sería realmente jugoso poder obtener fragmentos de un documento mediante este operador. La obtención del fragmento se podría producir en el servidor o en el cliente. Si hablamos de documentos XML, los fragmentos podrían estar expresados en XPath. Por ejemplo, supongamos un documento XML tal que:

<?xml version="1.0" ?>
<libros>
	<libro>
		<titulo>El manifiesto cluetrain</titulo>
		<autor>Rick Levine</autor>
		<autor>Christopher Locke</autor>
		<autor>Doc Searls</autor>
		<autor>David Weinberger</autor>
		<isbn>978-84-234-2693-5</isbn>
	</libro>
	<libro>
		<titulo>Organízate con eficacia</titulo>
		<categoria>Habilidades directivas</categoria>
		<autor>David Allen</autor>
		<editado>2006</editado>
		<edicion>1</edicion>
	</libro>
</libros>

…identificado por la URL

http://www.israelviana.es/libros.xml

. Sería fantástico poder obtener, a través de la dirección

http://www.israelviana.es/libros.xml#/libros/libro/autor

, una lista de autores. Este sistema podría complementar o incluso sustituir, en algunos casos, a los actuales servicios web, basados en XML y métodos remotos para obtener datos.

En fin, por imaginar que no quede…

“¿Tu sitio web es accesible?”, “Claro, el HTML es válido”

A veces me sorprendo de lo gustan algunas personas de ponerle las etiquetas de moda a sus proyectos. Por ejemplo, “accesible” o “2.0″. Quizá lo hagan para impresionar a sus jefes (que muchas veces desconocen esos términos), o quizá para salir en la prensa o blogs.

A esas personas les preguntas si su proyecto web es accesible y te contestan llenos de orgullo “sí, somos accesibles”. Así de sencillo, como quien declara que su proyecto trabaja sobre bases de datos MySQL o servidores Solaris. “Sí, somos accesibles”, y ya está.

Y es que con el tema de la accesibilidad, desde que en Internet se está promoviendo con fuerza, a esas personas les gusta “pillar la ola sin remar un poco mar adentro”. Creen que la accesibilidad se aprende en un tutorial por internet, se aplica y punto, como quien aprende maquetación sin tablas en los manuales del W3C, y creen que accesibilidad es programar XHTML válido (sí, aún hay gente que piensa que el HTML se programa). Quizá no hayan entendido qué es la accesibilidad.

Qué es la accesibilidad

Según la Real Academia Española, accesibilidad es la”cualidad de accesible”, y ésta a su vez:

  1. adj. Que tiene acceso.
  2. adj. De fácil acceso o trato.
  3. adj. De fácil comprensión, inteligible.

Es curioso cómo estas acepciones se asemejan a la definición de usabilidad, un término con el que los listillos 2.0 no se atraven a tratar con tanta facilidad. Así que como la RAE no anda muy puesta en las cosas de la WWW, busquemos en laherramientas automáticas son útiles pero no son esenciales.

La accesibilidad es un concepto cualitativo que se debe tener en cuenta en el desarrollo, mejora y garantía de calidad de un proyecto web (tanto sitios como aplicaciones web). Es una virtud que pueden o no tener, y en diferentes grados. Para alcanzarlo hay valiosos documentos y herramientas que nos pueden ayudar, pero la mayor baza para lograr la accesibilidad es pensar en el usuario final, en cualquier tipo de usuario final, pensar en su experiencia al utilizar el servicio y procurar que sea fácil.

XHTML válido: cómo y por qué

En HTML Blog encuentro 9 interesantes consejos para escribir código XHTML válido. Siempre le sugiero a la gente que escriba (y digo escribir, no generar :-P) XHTML válido (puede haber un interesante debate entre XHTML o HTML, sobre todo teniendo en cuenta las promesas de HTML 5), ya que al ser estándar respetamos las convenciones que los que saben más que nosotros han aceptado, al margen de darnos una cierta seguridad sobre la portabilidad de nuestras páginas.

Habitualmente, la gente que no se preocupa de validar su código, suele acercarse al HTML (sintaxis SGML) que al XHTML (sintaxis XML). Algunas diferencias son:

  • Nombres de las etiquetas en minúsculas. En HTMLlas mayúsculas eran un estándar de facto, en XHTML las minúsculas son obligatorias.
  • Poner barra en las etiquetas sin cierre:
    <img src="imagen.png" alt="Imagen" />

    (por cierto, alt obligatorio en todas las imágenes).

  • Caracteres especiales como entidades XML: "&quot;" en vez de ">".
  • Código JavaScript o CSS como contenido XML codificado (esto no lo hace casi nadie):
    <script type="text/javascript">
        /* <![CDATA[ */
        var myfunction = function(){
         
        };
        /* ]]> */
        </script>

Cada vez más gente se va adaptando a los estándares, sobre todo XHTML, ya que a la larga podrá adaptarse mejor a los estándares de la web semántica, tales como
RDFa.