Jornadas VEDA: Visualización de Ediciones Digitales Académicas

Barcelona, UAB, RedHD + ProLope, 21-23 de febrero de 2018

David Domínguez Herbón

Veinte reglas de operación…

  1. La técnica es la suma de procesos necesarios para obtener, a partir de un objeto técnico concreto, un objeto tecnológico prediseñado. Cualquier alteración en la técnica aplicada a dicho objeto técnico implica necesariamente una variación en el objeto tecnológico. Asimismo, cualquier alteración de diseño en el objeto técnico concreto obligará a la alteración de la técnica para concurrir a la obtención del objeto tecnológico previamente diseñado. En consecuencia, lo que es un objeto técnico para una técnica, es un objeto tecnológico para otra, e incluso puede considerarse un objeto teórico.
  2. Navaja de Ockham: la solución más simple para el programador es siempre la más acertada para el proyecto…, siempre que no derive de las limitaciones del programador. Por lo general, la solución más simple para el teórico es la más complicada de ejecutar en un proyecto, por lo que se debe atender siempre a la recomendación de quien estudia la técnica.
  3. Nunca se deben discutir cuestiones teóricas con un programador, salvo que sea el programador quien haga las preguntas necesarias conducentes a la discusión. El programador es un experto en objetos tecnológicos, no teóricos, pero su interlocución es condición sine quæ non para la óptima implementación de la técnica.
  4. La solución más barata ‒la menos onerosa a la Real Hacienda‒ es siempre la más acertada…, siempre que se pueda demostrar a las autoridades administrativas/burocráticas correspondientes que, de entre las muchas posibles razones, fue esa la que motivó la selección de dicha solución.
  5. ¡Que inventen ellos! Si ya está hecho, no hay necesidad de hacer algo nuevo, y si alguna de las opciones a disposición de los selectores es adaptable en mayor o menor medida a los fines del proyecto, previa deliberación con los responsables de su implementación técnica y tecnológica, deberá preferirse sobre las demás, a menos que obliguen a ello las condiciones administrativas/burocráticas.
  6. Ante cualquier debilidad de la técnica, siempre se debe preferir el mal menor. Esto no implica que los procesos estén siempre sujetos a su factibilidad (facilidad de ejecución).
  7. El control de los medios de producción debe permanecer en todo momento sujeto a la voluntad de las masas, es decir, que el control sobre los procesos, los objetos técnicos y tecnológicos y, por ende, sobre el desarrollo general del proyecto, debe en todo momento estar sujeto a la voluntad de los miembros del proyecto, de su directiva o de la sección de estos sobre la que recaiga dicha responsabilidad. La delegación de funciones en personal ajeno al proyecto siempre forzará una delegación de cierto nivel de toma de decisiones.
  8. Durante el desarrollo del proyecto y la implementación de sus técnicas asociadas se deben tener presentes varias circunstancias culturales: en primer lugar, aquellas referentes al momento de producción del objeto técnico fundamento del proyecto; luego, las circunstancias culturales de la producción del objeto tecnológico concreto; y, por último, las relativas al público a quien va dirigido el objeto tecnológico en cuestión.
  9. El diseño de la visualización debe estar sujeto a los principios de computación mínima. Estos principios están encaminados a la resiliencia, portabilidad y preservación tanto del proyecto como de los objetos y procesos técnicos que lo conforman.
  10. Todo puede ser explicado, así que todo debe ser explicado. Con el fin de promover la resiliencia del proyecto, reduciendo su mantenimiento y permitiendo la desvinculación del desarrollo de objetos técnicos y tecnológicos de las individualidades particulares, tanto el proyecto, como la técnica y el código se explicarán de la siguiente forma:
    • el proyecto debe ser documentado, para lo que se debe producir una documentación técnica que detalle, de forma pormenorizada, las formas de ejecución y las tomas de decisiones que condujeron a la selección de dichas formas, e incluir las reglas parciales a que estén sujetos los procesos técnicos del proyecto;
    • la técnica debe ser descrita, para lo que se debe elaborar un algoritmo de procesos que detalle, de forma gráfica, las formas procesuales en que se ha de llevar a cabo el paso del objeto técnico concreto al objeto tecnológico prediseñado;
    • el código debe contener comentarios insertos de forma que no obstruyan su ejecución y sean perfectamente claro, con el fin de hacerlo comprensible en su extensión a un lego, y dichos comentarios deben incluirse de conformidad con lo descrito para el proyecto y la técnica para evitar ambigüedades y promover la concurrencia de métodos.
  11. Por lo que a estas jornadas respecta, la visualización determina la forma del objeto digital, y no al revés: el output condiciona el input. Por tanto, se debe pensar siempre en la imagen para, a partir de ella, poder pensar el etiquetado que, sujeto a una técnica, proporcione el objeto técnico concreto deseado.
  12. No existen parámetros no visualizables: todo puede ser representado, pero no todo tiene por qué serlo, de manera que aquello que exista en el objeto técnico no tiene por qué existir en el objeto tecnológico. Por otra parte, no hay necesidad de agregar objetos a la visualización si estos no implicarán una mejora en eficiencia, en eficacia o en efectividad.
  13. Los metadatos son una sección del objeto técnico sin la que el objeto tecnológico carece de identidad. Unos metadatos deficientes conllevan la pérdida de sentido del proyecto, en lo general, y de los objetos técnico y tecnológico, en lo particular. Deben, por tanto, ser incluidos en ambos objetos, en la forma más completa posible, sean o no parte de su visualización.
  14. Existen diversas formas de diferenciar información visual –colores, tamaños, tipos, efectos…–, pero cuantas menos usemos, más eficiente, eficaz y efectivo será el objeto tecnológico resultante. Los principios de diseño a aplicar son, con poca diferencia, los aplicables a la representación de información cartográfica, pudiéndose entender el soporte visual del objeto tecnológico como un plano y, por tanto, el algoritmo de procesos como una ruta a seguir en dicho plano.
  15. Todo objeto web es contingente, pero muchos son totalmente innecesarios, siempre y cuando no pertenezcan a la estructura general de navegación e información. En este rubro podemos encontrar gadgets, widgets, paneles, marcos, feeds y otros objetos tecnológicos en html que incorporan información secundaria. Esta información, por su carácter secundario, debe siempre priorizar el auxilio a la comprensión de la información expresada en el objeto tecnológico concreto, por lo que cualquier delegación de responsabilidades sobre la gestión y contenido de esta información secundaria es nociva para la visualización.
  16. La homogeneidad es un requisito imprescindible para todos los objetos técnicos y tecnológicos. El conjunto de objetos técnicos debe mostrar homogeneidad entre todos sus miembros, y del mismo modo debe suceder con el conjunto de objetos tecnológicos. Los aspectos en los que dicha homogeneidad debe incidir son: tipo MIME, clase, metadatos, estándares y reglas aplicables, estructura, condiciones y comportamiento. Si uno sólo de los elementos de dichos conjuntos difiere en este aspecto de los demás, no puede ser considerado parte del mismo y provocara una marcada divergencia que incidirá negativamente en la percepción del proyecto.
  17. Cualquier esquema de exportación de los objetos técnicos y tecnológicos digitales debe ser tomado en consideración a la par que se diseña el algoritmo técnico, con el fin de evitar incoherencias o redundancias entre procesos. Esto debe ser realizado y debe permear toda toma de decisiones, aunque dichas actividades no estén contempladas en el proyecto.
  18. La preservación debe ser, siempre, un objetivo a perseguir (ver 6). Las circunstancias e implicaciones del método considerado para la preservación de los objetos técnicos y tecnológicos son parte del mismo proceso técnico, lo que obliga a su documentación conjunta con el resto del proyecto. Son, pues, condiciones para pensar los procesos de obtención de los objetos técnicos concretos, pero no tanto los objetos tecnológicos derivados.
  19. El objeto tecnológico es una exportación a un soporte distinto de aquel en el que se encuentra el objeto técnico, y no una forma del mismo objeto. Un documento XML/TEI no está diseñado para visualizarse per se en una pantalla, si no es mediando un software de interpretación para ello, por mínimo que este sea. Cualquier actividad analítica pensada para realizarse sobre el objeto técnico concreto debe poder ser aplicada de manera análoga sobre el objeto tecnológico, no así al revés.
  20. La "virtualidad" de una publicación en línea tiende a la sobreestimación del análisis de flujos web (siempre queremos saber quién nos visita…), pero cualquier diseño encaminado a obtener información analítica de este tipo debe tener en cuenta los siguientes aspectos técnicos:
    • La apertura de los objetos tecnológicos al tráfico financiero de metadatos.
    • Las condiciones de compartición de la licencia.
    • Las condiciones de desarrollo del proyecto a medio y largo plazo.
    • Los sistemas y formas de exportación previstas para los objetos técnicos y tecnológicos.
    • La implementación dentro del algoritmo y el almacenamiento de dicha información.
    • La frecuencia de publicación de nuevas informaciones u objetos tecnológicos concretos.
    • La privacidad del visitante.

…y una petición desesperada:

¡JAVA™ NUNCA ES UNA OPCIÓN! O, al menos, no lo es como base para el desarrollo de un proyecto de estas características. No le den una oportunidad. Cualquier cosa es mejor que Java™. Tengamos en cuenta las siguientes verdades, que constituyen verdadero dogma de fe:

  • Java™ es el hijo que nunca quisieron tener Damien y la niña de El Aro.
  • Java™ ha sido testado en animales, está genéticamente modificado y no es kosher.
  • Java™ es el malo en una película de Sergio Leone: feo, machista, recurrente y sobrevalorado.
  • Skynet™ y la Web de la Moncloa funcionan con Java™.
  • Java™ es la Encarnación del Demonio y el Fin de los Tiempos.
  • El uso prolongado de Java™ provoca rechinar de dientes, rasgar de vestiduras y condenación eterna.
  • Si ya es usuario de Java™, aún hay tiempo para alcanzar la salvación.

El presente documento, "Jornadas VEDA: Visualización de Ediciones Digitales Académicas", creado por David Domínguez Herbón:

Para cualquier información relativa al desarrollo de estas jornadas, al desarrollo de actividades dentro del campo de las Humanidades Digitales, o si quiere sugerir cambios o modificaciones a este documento, por favor, contacte al correo electrónico herdado@protonmail.com o via Twitter al usuario @herdado_HD.

Última actualización: lunes, 19 de febrero de 2018, 16:00 horas

Report abuse