Documentos. Tipos.

Modelo basado en formulario

Derivado del anterior (documento-cloze), una segunda propuesta de automatización de la composición del documento consiste en la identificación de variables y su asociación a controles de formulario. Este cambión es mucho más que de forma, ya que implica el uso intensivo de controles de formulario (esto es: de elementos de input) y, lo que es más importante, el empleo de procedimientos basados en un lenguaje de programación.

Mientras que en el modelo documento-cloze no es necesario recurrir a la programación, en el modelo basado en formulario sí, ya que esos controles sirven de bien poco si no son manejados mediante código. Cierto que se pueden emplear como sustitutos de los guiones bajos que identifican las posiciones de las variables en el documento-cloze (y es posible que esta sea una fase evolutiva intermedia entre ambos procedimientos), que el salto que implica trabajar con los controles de formulario como recurso input viene dado por la formulación de un procedimiento basado en el mecánica básica de un algoritmo: input - procesamiento - output, esto es: viene dada por la comprensión del procedimiento como desarrollo y concreción de un script.

Tomando como referencia el documento anterior (a fin de facilitar la exposición del desarrollo de la metodología de automatización), el modelo-formulario supone asociar las variables identificadas anteriormente con un objeto-control (de formulario), lo que conlleva varias ventajas (aunque no son precisamente destacables en el ejemplo elegido), con es la simplificación del número de variables cuando la información contenida en el documento original se repite (en este caso es suficiente con una única variable y con un único profeso de recogida de datos).

La fase input se independiza además de la escritura del documento, por lo que cambia radicalmente la forma de trabajo, diferenciándose las tres fase del desarrollo del script indicadas antes, aunque la segunda (el procesamiento) queda oculta al usuario, ya que se concreta únicamente a nivel de código.

Obsérvese además que precisamente en esta fase de resuelve lo que anteriormente incrementó la carga de trabajo en la escritura del documento: los segmentos de texto sujetos a concordancia gramatical, ya en el documento-cloze  optamos por resolver de un modo un tanto "chapucero" (v.g. el niño/la niña) se resuelve ahora (no sin su coste correspondiente) de forma automatizada y oculta al usuario: se desarrolla en la fase procesamiento haciendo uso de una estructura condicional (if...else), lo que da a nuestra solución (docap) una funcionalidad muy superior a la que podemos alcanzar con la solución-cloze. Eso sí, a costa de incrementar la carga de trabajo de creación del script, en extensión y, llegado el momento, también en complejidad.

Será precisamente este incremento de complejidad y extensión la que nos obligue a buscar soluciones que faciliten la simplificación del procedimiento, pero este es tema para otra entrada.

Documento. Desde este enlace [pendiente] puedes acceder a una versión-formulario de esta segunda propuesta de procedimiento de automatización. Aunque caben diferentes soluciones, planteo aquí la que considero mejor se ajusta al objetivo que se pretende, que requiere el uso de dos servicios (Calc y Writer), con lo que esto implica de mayor complejidad. Esto supone que, en la práctica, se pueden plantear soluciones más sencilla, basadas únicamente en un servicio (Writer).

Documentos. Tipos.

Modelo basado en la identificación de variables

El modelo de automatización más básico, tanto que es compatible con tecnologías previas a la era digital, es el que podemos definir como se indica en el título de esta entrada y que también se puede denominar texto cloze.

El uso de este término no termina de ajustarse, por su significado, al procedimiento de automatización que se pretende describir, pero sí es adecuado en su apariencia y resulta revelador en términos de procedimiento subyacente.

Lo que se busca dentro de este planteamiento es identificar qué datos son objeto de modificación (datos variables) y marcarlos como tales mediante el procedimiento de suprimir el contenido concreto bien por guion bajo (en realidad, una serie suficientemente extensa de guiones) sobre el cual se escribe (cuando así se considera) un descriptor del contenido esperado.

Lo curioso (por decirlo de alguna manera) es que, a pesar de la sencillez y simplicidad del procedimiento y de su antigüedad, sigue siendo usado aun hoy en día, cierto que modernizado mediante el uso de procesadores de texto y únicamente como herramienta para "personalizar" documentos muy simples (tampoco es que, como procedimiento, dé para mucho más). En parte esta perdurabilidad se debe precisamente a su simplicidad (no requiere conocimientos informáticos especiales, ni siguiera a nivel de usuario avanzado, aunque se beneficia del empleo de utilidades específicas) y al hecho de haberse beneficiado de la flexibilidad de tratamiento que es posible darle con los procesadores de textos. Pero tampoco se nos debe olvidar que, tras esa aparente sencillez se oculta una idea fundamental y básica en todo procedimiento de automatización de textos: la diferenciación entre texto fijo y datos variables.

Nos obstante, lo que ahora nos ocupa no es el análisis de la tipología segmental del documento (cuestión ésta que, aunque en esta subsección esté implícita, tendrá espacio propio en otra) como la conformación de procedimientos de automatización de textos; y desde esta perspectiva resulta que un texto cloze, por vigente que siga estando, tiene poco que ofrecer.

Donde tiene plena vigencia, aunque no exenta de críticas, es como herramienta de evaluación, siendo frecuente encontrar ejemplos de este uso. Por este motivo tendremos ocasión de volver a hablar de este procedimiento en la sección correspondiente (Aprendizaje).

Aquí vamos a ejemplificar este modelo mediante la presentación de un ejemplo concreto, aunque parcial, de uso. Y digo parcial porque en realidad se complementa con un procedimiento basado en el uso de tablas con funciones de elección del dato que se considere ajustado a las circunstancias.

Me refiero a un documento de solicitud de beca NEE, pensado para ser complementado tanto manualmente (no es extraño que esta alternativa de uso se de en este tipo de recurso, incluso a día de hoy) como mediante el procesador de textos. La parte cloze es la siguiente (a continuación reproduzco imagen, al final dejo acceso al "original"):

A continuación sigue una serie de tablas para elección de opciones y un segundo cuerpo de texto similar al expuesto y, de nuevo una tabla para elección múltiple.

Obsérvese que, aunque se denomina texto cloze, en realidad se utilizan dos procedimientos de personalización: el cloze propiamente dicho (se reconoce por el uso del guion bajo) y la opción generalmente de género (alumno/alumna). Este segundo recurso indica que, en este caso, se trata de un modelo documental pensado para emplear el procesador de texto; en caso contario se presentarían dos modelos, uno para alumnos y otro para alumnas, eliminando la opcionalidad de género y manteniendo únicamente el formato cloze.

Aunque tal y como está es suficiente para facilitar la personalización de los datos, podríamos facilitar su cumplimentación utilizando dos estrategias diferentes que tienen en común requerir un mayor conocimiento de las funcionalidades del procesador de textos, para lo que (en este caso) sería necesario utilizar LO-Writer en lugar de Word: el uso de marcadores o el empleo de palabras-clave rellenando los huecos.

Mediante marcadores, posteriormente podríamos acceder directamente a las distintas posiciones haciendo uso del navegador (menú Ver | Navegador | Marcadores).

La segunda opción requiere mayor preparación, ya que cada palabra debe ser única y descriptiva, puesto que lo que se pretende es utilizar la funcionalidad Buscar y reemplazar (menú Editar | Buscar y reemplazar).

Realmente ninguna de las dos opciones es suficientemente atractiva ni funcional como para que sea conveniente su uso, por lo que, por lo general, este modelo de automatización se basa, en la practica, en el uso del procesador de textos como única herramienta tanto de preparación del documento-base como para su cumplimentación personalizada.

 

Documento. En este enlace puedes descargar el documento completo en formato .doc (Word), pero recuerda que es un documento no actualizado (fue diseñado para el curso 2018/2019), por lo que no se ofrece como recurso para la intervención.

Documentos. Automatización.

Modelos básicos de automatización de textos

Creo haber hablado ya de este tema en anteriores entradas, pero es necesario ahora sistematizar esta temática a fin de contextualizar adecuadamente su tratamiento.

Recurrir a algún tipo de estrategia de ahorro de tiempo y trabajo en la creación de documentos es práctica común en el ámbito de la intervención de los SEO (no sólo los SEO) y muy anterior al uso generalizado de los recursos informáticos, aunque la llegada de la "era de lo digital" ha facilitado enormemente la tarea y ha dado lugar a planteamientos de trabajo no pensables antes de que se generalizara el uso de los ordenadores.

No obstante, el predominio del uso del procesador de textos no ha cambiado tanto como sería de esperar en enfoque de este proceso de automatización, ya que sigue siendo habitual que la práctica se concrete como uso de documentos-modelo y formas similares de trabajo, lo que no se puede considerar automatización en sentido estricto. Y no es problema menor que nos encontremos actualmente ante la posibilidad de dar el salto desde estas formas primitivas de trabajo al uso de la mal llamada IA y los riesgos que conlleva de pérdida de competencia profesional.

Se trata en esta sección de recorrer e informar sobre las diferentes formas en que se puede llevar a cabo la tarea de automatizar (semiautomatizar sería más correcto) la composición de textos, concretamente de los documentos profesionales que competen y ocupan (a veces en exceso) a los profesionales de los SEO.

Sólo en síntesis y a modo de introducción señalo a continuación lo que considero son los modelos pre-IA de automatización de textos, empezando por lo que denomino modelo texto cloze y finalizando (provisionalmente) por lo que llama modelo basado en matrices de datos; entre ambos se puede identificar un modelo que se caracteriza por el uso de formularios, aunque no es ésta su única peculiaridad, como tampoco lo son en los otros dos lo que sirve para denominarlos. De todo esto hablaré en entradas sucesivas dentro de esta misma sección (Textos), a la vez que iré reformulando su estructura y contenidos, ya que el enfoque actual no se corresponde plenamente con el que animó inicialmente su diferenciación primitiva dentro de este blog.

Evaluación.

Justificación del tratamiento diferencial de la evaluación

Queda dicho en una entrada de similar objetivo que esta, que desde la perspectiva del blog está justificada la diferenciación de dos secciones para el tratamiento de las tareas como docap. En esta entrada me interesa clarificar cómo afecta esta diferenciación al contenido de la sección que aquí se justifica: Evaluación.

Referencia

Gracias a la diferenciación del contenido en dos secciones, podemos entrarnos en ésta en el desarrollo de propuestas específicas de recogida y análisis de datos y en la formalización de procedimientos de automatización de informes de resultados. Nos olvidamos aquí de las diferentes problemáticas que conlleva la elaboración de recursos diseñados para ser utilizados directamente por el alumnado.

Esta omisión, que lo es relativamente dado que es objeto de atención en la sección del blog que complementa la presente, nos permite atender específicamente a lo que resulta nuclear en la evaluación, así como enlazar con las problemáticas tratadas respectivamente en la sección Textos (la automatización de informes) y Datos (el análisis de datos), a la vez que provee a la sección Aprendizaje de los necesarios módulos complementarios para el desarrollo integral de instrumentos de intervención.

Aunque al menos inicialmente el soporte-base será LO-Calc y OOo Basic como lenguaje de programación, es de esperar que seamos capaces de implementar también el lenguaje Python, bien sea manteniendo el uso del soporte anterior (Calc, es decir, una hoja de cálculo), bien empleando otros alternativos. En todo caso, lo que realmente importa aquí es que generemos modelos de trabajo que permitan automatizar integralmente, hasta donde esto es posible, la evaluación de pruebas, dadas las ventajas que conlleva dicha automatización para el trabajo docente y más aun de los SEO.

Aprendizaje.

Motivos que justifican esta sección.

Aprendizaje y Evaluación forman una unidad de contenido, igual que las entradas que se ubican dentro de la sección Textos o las que se encuentran en la sección Datos: Ambas hacen referencia a una unidad que podríamos llamar Tareas de aprendizaje y de evaluación, pero que aquí se presentan diferenciadas por motivos que explicaré en esta entrada.

Referencia

Inicialmente ambos contenidos se han presentado en una única sección, pero he observado que esto genera ciertas dificultades a la hora de dar unidad al grupo de entradas. El problema no viene dado por la diferencia entre tareas de evaluación y las de enseñanza-aprendizaje.

La diferencia no viene dada por la finalidad (que no resulta tan diferente, en realidad, viene dada por el objetivo con el que se crea el recurso o docap: si se pretende desarrollar un proceso integral de aplicación, análisis de datos y evaluación de resultados, o si prescindimos del primero de los contenidos y nos limitamos (es un decir) a recoger, analizar y evaluar los datos resultantes de la aplicación de un material que puede no ser relevante en si mismo o que los derechos de autor nos impiden reproducir, obligándonos a manejarlos "en papel", tal y como los presenta la editorial que los publica.

Aunque esta distinción carezca de relevancia para el planteamiento original de la sección (incluso para la misma intervención del profesional) sí es sustancial para el desarrollo del planteamiento del blog y para la elaboración de materiales (docap) por lo que me interesa liberar a la sección Evaluación de la confusión que conlleva no diferenciarla de Aprendizaje. De hecho, en estos momentos (febrero/2025) los contenidos de ambas (especialmente de Evaluación) mantiene esa confusión que iré eliminando paulatinamente.

Esta diferenciación también beneficia a Aprendizaje, ya que me permitirá centrarme en lo nuclear de la misma, empezando por la formulación de los diferentes tipos de ítem, dejando que su complemento evaluativo sea resuelto (en cuanto docap aplicable) mediante módulo(s) desarrollado(s) en Evaluación. Por este motivo aquí los temas que se traten estarán más centrados en la presentación de los contenidos/materiales y en la interacción del usuario con ellos. También tendrá cabida el tratamiento de determinados instrumentos y servicios, complementando el tratamientos que reciban en otras secciones del blog.