La Plataforma de Contratación y el Registro de Contratos brindan acceso a dos conjuntos de datos diferentes, con lo que actualmente la contratación pública de Cataluña está repartida entre dos servicios digitales diferentes.

Existen razones de naturaleza administrativa para esta circunstancia, pero algunos de nuestros usuarios las deconocen. La Administración tiene su lógica y sus complejidades, pero esta no debe trascender al ciudadano. Es la Administración quien debe realizar el esfuerzo de adaptarse a la visión del ciudadano, y no al revés.

Marc y Paula no conocen —y no tienen por qué— las especificidades de un contrato menor.

• Marc está investigando las adjudicaciones a un contratista, pero en la Plataforma no obtiene la fotografía completa. Acude al Registro para ampliar sus datos, pero ahora debe conciliar los resultados de ambos portales, lo que le supone un esfuerzo adicional. Marc no entiende por qué no hay un punto de acceso único desde el que explorar todas las compras públicas de Cataluña.

• Paula ha hecho una búsqueda en internet y ha llegado a la Plataforma, pero ignora (discoverability) que, para tener una visión completa, debe consultar además el Registro. Obtiene resultados pero no encuentra algunos contratos que, en cambio, sí lee en un canal de Telegram con bulos y desinformación. Ello le hace pensar que algo está siendo ocultado, lo que refuerza la sensación de opacidad y conspiración que difunde el canal social al que se ha suscrito. Paula ignora que además de la Plataforma, existe también el Registro.

Publicar los contratos repartidos entre la Plataforma y el Registro dificulta a todos los usuarios obtener una visión de conjunto de, por ejemplo, el volumen de negocio de un contratista con los organismos públicos.

Recomendación

Recomiendo unificar la Plataforma y el Registro en un único servicio digital. Esto, además de satisfacer las expectativas de los usuarios menos familiarizados con la lógica de la Administración, reduciría los costes de mantenimiento de operación y la fricción de todos los usuarios, también los que acceden desde los organismos públicos.

Tal integración, sin embargo, no parece inmediata. El desacoplamiento (impedance mismatch) entre los modelos de datos de la Plataforma y el Registro provoca que una mera agregación sea inviable. Los costes de tal unificación —si bien podrían estudiarse— y otras fricciones interadministrativas probablemente obliguen a postergar esta acción.

El primer acceso del usuario a la Plataforma se ve interrumpido por un aviso de cookies que bloquea (modal) cualquier interacción con el sitio. Esto supone una fricción entre el usuario y el servicio. ¿Es necesaria?

La obligación legal de informar y recabar el consentimiento del usuario no es aplicable a todas las cookies, habiendo algunas excepciones para cookies que son necesarias para el funcionamiento del sitio y no pretenden realizar un seguimiento de la actividad del usuario.

La política de cookies de la Plataforma instala e informa de las cookies de Google Analytics, pero no informa de las que instala YouTube. ¿Es necesario que la Plataforma de Contratación de Cataluña instale en el navegador del usuario cookies de Google y de YouTube que pueden suponer un compromiso de su privacidad y, además, activan la obligación legal de presentar un incómodo aviso de información y consentimiento?

Recomendación

Si bien esto requiere de la consulta a los técnicos que implementaron la integración con Google Analytics y YouTube, parece razonable pensar que las cookies de ambos servicios externos son prescindibles y, por tanto, el aviso modal que ahora sale al encuentro del usuario en su primer acceso a la plataforma, podría desaparecer junto con la fricción que supone:

• Google Analytics. Las versiones más recientes del servicio permiten el registro del tráfico sin la mediación de cookies. Pero, a mayores, ¿es realmente necesario instalar Google Analytics? ¿Se está haciendo un seguimiento activo y frecuente del tráfico del portal para implementar mejoras?

  El análisis de tráfico es habitual en sitios de comercio electrónico, donde arroja luz sobre el comportamiento de los usuarios y la eficacia de los canales de adquisición para optimizar las inversiones en marketing digital y maximizar el retorno económico del sitio. Los sitios web de la Administración, sin embargo, poco tienen que ver con esta descripción. No hay compras en línea, ni inversión en publicidad digital, y el servicio ha de estar en línea cualquiera que sea su tráfico. La recomendación del autor de este informe es, simplemente, descartar completamente Google Analytics. O, cuando menos, adoptar la versión que no instala cookies.

• YouTube. La presentación de vídeos de esta plataforma podría hacerse también desde el dominio oficial youtube-nocookie.com, librando así, de nuevo, la instalación de cookies que comprometen la privacidad del usuario de la Plataforma de Contratación al tiempo que obliga a la presentación del molesto aviso de información y solicitud de consentimiento.

La eliminación de todas las cookies de seguimiento reduciría el esfuerzo de mantenimiento y el riesgo legal: al no haber cookies reguladas por la normativa, desaparece la necesidad de revisar periódicamente la política de cookies. Y, con ella, el riesgo de incumplir la normativa concerniente.

Existe en el producto digital de AOC para los portales de transparencia de los ayuntamientos un enlace para la descarga de todos los datos. Pero está roto y lleva a una página de error 404.

Recomendación

Corregir el enlace roto. E, idealmente, integrar una herramienta de monitorización de excepciones como Sentry, lo que permitiría detectar este problema y otros errores que impactan negativamente en la experiencia de usuario tan pronto como se producen.

Al menos en el portal de transparencia de Manresa, los botones de descarga y acceso a los datos aparecen aparentemente duplicados.

Quizá la primera fila de botones se refiere a la primera tabla de contratos; y la segunda fila de botones, a la segunda tabla. Pero esto no es evidente para el usuario. Y supone una redundancia, además, antiestética. Por otro lado, representa una incoherencia de diseño (design inconsistency), por cuanto, sin que exista una razón clara, una tabla presenta sus acciones de descarga debajo y la otra, en cambio, justo encima.

La incoherencia puede confundir y sorprender al usuario. Y, además, se extiende también —entre otros— a la posición de los controles de paginación, que están encima de la primera tabla pero debajo de la segunda. Y al filtro de resultados, que —al menos para el citado caso de Manresa— solo existe en la segunda tabla.

Recomendación

Aplicar el principio de mínima sorpresa y realizar los cambios necesarios para que los elementos análogos de la interfaz de usuario —en este caso, las tablas de contratos— se comporten de manera igualmente análoga.

No parece equivocado pensar que, en general, el interés de un contrato decrece con el tiempo. Y que los resultados de las búsquedas tienen para nuestros usuarios más valor cuanto más actuales.

El argumento contrario también parece razonable: los contratos antiguos tienen un interés más histórico o referencial que comercial o informativo.

Sin embargo, los primeros resultados de la tabla de contratos en el portal de transparencia muestra de manera predeterminada los contratos más antiguos de la base de datos. Contratos que hace años que fueron adjudicados y ejecutados. Esto obliga al usuario a avanzar manualmente hasta la última página para encontrar los expedientes más recientes.

Recomendación

Cuando existan tablas de contratos, recomiendo mostrar los contratos en orden cronológico inverso: primero los que más recientemente han sido publicados, licitados, adjudicados, formalizados o modificados.

La imagen institucional es uno de los elementos más sensibles del diseño de un servicio público digital. Sin embargo, es también uno de los elementos más maltratados y desatendidos. Y es difícil transmitir al ciudadano una imagen de respeto y profesionalidad cuando el emblema mismo del organismo público es un mapa de bits borroso por una mala compresión.

Agrava esta situación la popularización, en los últimos años, de las pantallas de alta densidad de píxeles.

Los pictogramas y marcas deben mostrase en formatos vectoriales (SVG). A diferencia de los formatos de mapa de bits, los gráficos vectoriales se aprecian con calidad y nitidez a cualquier resolución y en cualquier pantalla.

El emblema de la Generalitat de Catalunya es un mapa de bits tanto en la cabecera como en el pie de página del Registro, pero en cambio se muestra en forma vectorial al pie de la Plataforma.

Recomendación

Utilizar siempre gráficos SVG para marcas, logos y pictogramas.

Los contratos son mostrados al ciudadano en tablas, pero no todas las columnas alojan el mismo tipo de contenido. Años, importes o códigos de expediente son datos breves que se adaptan bien a una estructura tabular. El objeto de un contrato, por el contrario, es texto mucho más extenso, que en algunos casos puede llegar a contar con cientos de palabras.

Para limitar la extensión del objeto de los contratos a lo que razonablemente cabe en una celda de una tabla, se eliden yuxtaponiendo unos puntos suspensivos.

Pero la elipsis se está haciendo cortando drásticamente a partir del 150º caracter. Esto provoca que las celdas tengan una altura desigual (algunas tienen tres, y otras cuatro líneas). Y que la elisión y los puntos suspensivos queden en posiciones arbitrarias donde cabría más texto. El programador no puede controlarlo.

Recomendación

Utilizar la propiedad CSS line-clamp, que resuelve elegante y simplemente este problema. Véase este ejemplo en CodePen.

Los céntimos de euro no son significativos para el usuario, y sustraen un espacio importante en las reducidas celdas de las tablas de resultados. Igualemente el símbolo del euros es redundante y puede explicitarse una única vez en la cabecera de la columna, no en cada celda.

Como se aprecia en las imágenes adjuntas, esto reduce la cantidad de información superflua en la tabla, mejora la legibilidad de los importes y reduce la carga cognitiva en el usuario.

Los céntimos de euros sí deben mostrarse, em cambio, en la página dedicada a cada contrato, donde no existen las limitaciones de espacio impuestas por la estructura tabular.

Recomendación

Redondear al euro, en las tablas de resultados, todos los importes económicos. Y quitar el símbolo del euro, por redundante, sustituyéndolo por una mención en la cabecera de la columna.

Tradicionalmente los programadores hemos abusado de las tablas como contenedor visual para presentar datos al usuario. Seguramente porque los registros de las bases de datos relacionales se reúnen en un contenedor lógico también denominado tabla.

Pero las tablas como contenedor lógico no tienen que ver con las tablas como componente presentacional. En el diseño de interfaces de usuario las tablas solo son adecuadas para datos de naturaleza tabular. Y los contratos públicos encajan muy mal en esta definición, tal como se aprecia en las siguientes capturas de pantalla.

En la implementación actual, hay tantas columnas (19), que no caben. Esto fuerza al usuario a realizar un incómodo y no evidente desplazamiento (scroll) horizontal. El aprovechamiento de la superficie útil de pantalla es asímismo pobre, pues la mayoría de las celdas contienen grandes cantidades de espacio libre, mientras que las columnas con mucho texto, como Descripción del expediente o Contrato, no caben y se ven forzadas a una estrechez prácticamente imposible.

Recomendación

Recomiendo descartar las tablas para maquetar listas de contratos, y adoptar en su lugar listas o cajas. Y mostrar en estos resultados solo los datos más relevantes de cada contrato, presentando todos solo cuando el usuario abre la vista detallada de uno.

La presentación columnar en forma etiqueta: dato, tradicional de la representación de modelos de datos, resulta artificiosa en las interfaces de usuario.

Contrato: menor
Tipo: servicios
Adjudicatario: ACME, S. A.
Duración: 1 mes y 9 días
Importe: 123.456 €

Muchas de estas etiquetas, además, son omitibles porque el dato ya revela su propia naturaleza.

Recomendación

Recomiendo emplear proposiciones y conectores lingüísticos para construir frases naturales con los datos, evitando —cuando sea posible— la forma etiqueta: dato.

Contrato menor de servicios — 1 mes y 9 días de duración
Adjudicado a ACME, S.A por 123.456 €

Esto ha de abordarse atendiendo a la naturaleza multilingüe de los portales de contratación y conectando los datos con conectores comunes a plurales y singulares.

La contratación pública es un proceso, y durante su ciclo de vida los contratos transitan por varios estados: como mínimo la licitación se anuncia, el contrato se adjudica y finalmente se formaliza.

El ciudadano al que nos dirigimos frecuentemente desconoce estas complejidades, motivo por el cual puede ser útil informarle del estado del contrato en el contexto del proceso de contratación.

Recomendación

Recomiendo presentar la información del estado del contrato en el contexto del proceso de contratación.

Los contratos públicos se presentan actualmente al ciudadano en una tabla ordenable, cada una de cuyas filas contiene un pictograma que, al ser tocado o pinchado, abre una ventana modal con los detalles del expediente.

Sin embargo, la implementación de este mecanismo modal no proporciona una dirección URL unívoca a cada contrato. Esto, en la práctica, impide a los usuarios enlazar, compartir o guardar un contrato en sus marcadores.

Recomendación

Recomiendo asignar a cada contrato una dirección URL única, a ser posible corta, que presente automáticamente la ventana modal con los detalles del contrato al ser abierta por un navegador. Esto permitirá a los usuarios guardar y compartir contratos.

Las direcciones URL son un identificador técnico de un recurso en línea. Cada recurso —e, idealmente, cada estado significativo de la interfaz de usuario— ha de disponer de una dirección URL única. El usuario ha de poder consultarla en las barras de direcciones y de estado de su navegador, pero se considera una buena práctica no mostrarlas directamente como un dato en la interfaz.

Las direcciones URL pueden ser largas y crípticas, y amedrentar a algunos de nuestros usuarios o provocar su desconfianza.

Modificaciones de contratos:
http://www.manresa.cat/web/article/6073-modificacions-de-contractes

Recomendación

Recomiendo sustituir las direcciones URL visibles en la interfaz de usuario por un texto descriptivo del recurso al que enlazan. Seguirán siendo interactivas, pero más legibles.

Véanse las modificaciones de contratos en el portal del Ayuntamiento.

Es frecuente que la descripción del objeto de un contrato contenga saltos de línea, retornos de carro o tabulaciones. Actualmente estás secuencias de control del flujo del texto se están mostrando en la interfaz de usuario como \n, \r o \t.

Recomendación

Reemplazar por espacios las secuencias \n, \r y \t —entre quizá otras— antes de enviarlas a la interfaz de usuario.

La página que muestra la relación de contratos adjudicados en algunos ayuntamiento contiene dos tablas. La paginación y reordenación de la primera es instantánea, porque se precargan desde el servidor todos los resultados y estas operaciones las realiza el navegador del usuario. En el caso de la segunda, en cambio, la paginación, reordenación y filtrado puede llevar varios segundos, porque estas operaciones se solicitan al servidor.

Desde el punto de vista del usuario es más conveniente precargar todos los resultados desde el servidor una única vez y cachearlos para evitar descargas redundantes. Esto, sin embargo puede ser desaconsejable si el volumen de datos es muy grande.

Recomendación

Recomiendo precargar todos los datos desde el servidor y realizar las operaciones de ordenación, paginación y filtrado en el navegador. Los datos JSON descargados tienen una razón de compresión de en torno al 85 % si Brotli o gzip están habilitados en el servidor, lo que reduce drásticamente el ancho de banda y el timpo de descarga. Por otro lado, el documento JSON contiene datos que aparentemente no son mostrados en las tablas, y que podrían quitarse para reducir el volumen de los datos.

Las columnas de la tabla de licitaciones en trámite no tienen títulos descriptivos para humanos: CODI_EXPEDIENT, TIPUS_CONTRACTE, FASE_PUBLICACIO, VALOR_ESTIMAT_CONTRACTE…

Recomendación

Titular las columnas de forma legible.

Se ofrecerá al usuario un único buscador de contratos, contratistas y órganos de contratación de Cataluña. Este será el punto de entrada único a los expedientes de contratación y a la experiencia de búsqueda.

Se abstraerán así para el ciudadano las particularidades internas a la Administración que provocan la actual coexistencia independiente del Registro Público de Contratos y la Plataforma de Contratación. Ello sin perjuicio de que, de puertas a dentro de la Administración, sigan ambas coexistiendo durante un tiempo como proyectos separados.

Este buscador agregará los resultados de todos los órganos de contratación, haciendo posible búsquedas intermunicipales y el acceso horizontal a la contratación de todos los organismos desde un único punto de acceso.

Idealmente, estará desplegado en su propio dominio o, al menos, en un subdominio. Y contará con una dirección URL corta, pronunciable y recordable. Se evitarán las abreviaturas. Por ejemplo:

• contractacio.cat
• contractes.gencat.cat

Nótese que la dirección del servicio es una parte relevante de la marca del portal, que impacta en su encontrabilidad y la de los contratos, y que forma parte visible de los enlaces que la ciudadanía compartirá en la web, canales privados de mensajería o las redes sociales.

La interfaz del buscador consistirá en un único campo de entrada de texto.

Un texto de marcador de posición (placeholder text) y el pictograma de una lupa sobreimpreso en la parte derecha del campo expresarán al usuario que se trata de un buscador.

En el momento de la carga de la página el campo recibirá automáticamente el foco del teclado. El cursor de texto intermitente invitará al usuario a teclear inmediatamente.

No habrá siquiera botón Buscar.

El buscador arrojará resultados de búsqueda mientras el usuario teclea.

Esto incentivará al usuario a buscar más y refinar sus búsquedas, pues el coste percibido de cada búsqueda se reduce visiblemente al evitarse la pulsación de un botón de búsqueda y la recarga de la página.

Técnicamente, el programador implementará un mecanismo de debounce para que no se acumulen llamadas concurrentes cuando el usuario no ha terminado aún de teclear su pesquisa.

Los resultados se presentarán sin paginar, con desplazamiento (scroll) infinito cuando el usuario se aproxima hacia el final del mosaico de resultados.

Para que la experiencia de búsqueda sea satisfactoria, el servicio habrá de arrojar resultados en tiempos cortos.

He comprobado con la base de datos de la estatal Plataforma de Contratación del Sector Público (PLCSP) que es posible devolver al usuario resultados de tiempo real con una cadencia inferior a 400 milisegundos para la mayoría de las búsquedas. Para esta prueba de concepto utilicé un clúster de Elasticsearch en un entorno de producción. Serán probablemente posibles tiempos de respuesta similares con otras arquitecturas.

El corpus de expedientes de contratación pública de Cataluña es un orden de magnitud más pequeño que el de la PLCSP.

El buscador devolverá tres tipos de resultados: contratos, contratistas y órganos de contratación.

Cada resultado se presentará en forma de tarjeta, teniendo cada tarjeta unos datos y diseño diferente en función del tipo de resultado.

Las tarjetas de los resultados se dispondrán en forma de mosaico (masonry).

Los resultados de cada búsqueda se ordenarán según su relevancia, priorizándose primero los órganos de contratación y los contratistas coincidentes —que serán generalmente pocos— y después los contratos, más numerosos.

Los controles para ajustar la búsqueda que se han omitido de la interfaz inicial aparecerán una vez el usuario ha cursado una búsqueda y se han presentado resultados.

Serán controles contextuales, ajustados a los resultados de la búsqueda realizada.

Por ejemplo, el control de rango (slider) para filtrar los contratos por su presupuesto económico presentará un valor mínimo y máximo coincidente con el presupuesto del valor mínimo y máximo de todos los contratos resultantes de la búsqueda.

Por ejemplo, si hay pocos resultados de búsqueda no se mostrarán controles para su filtrado.

El buscador implementará un pequeño diccionario de sinónimos construido a medida para este caso de uso.

Así, y por ejemplo, el término ayuntamiento será sinónimo de ajuntament y devolverán ambos los mismos términos. Ídem con terrassa y tarrasa, catalunya y cataluña y otros términos y topónimos.

El motor realizará una búsqueda difusa (fuzzy), de modo que será tolerante a erratas tanto en la cadena de búsqueda introducida por el usuario como en los datos indexados.

Idealmente se indexarán y mostrarán los nombres de los contratistas normalizados según el censo de obligados tributarios de la agencia tributaria autonómica o estatal. Para la AEAT estatal se trata del Modelo 030: Comprobación de un NIF de terceros a efectos censales.

Se presentarán al usuario datos del total adjudicado al contratista y de la distribución de este total entre los órganos de contratación.