Inicio

OrientAsLO y la competencia digital de los SEO

Después de varios intentos de formulación de este proyecto, llego a su cuarta versión habiendo recorrido un camino nada despreciable en producción y aprendizaje, aunque (reconozco) no siempre satisfactorio (de ahí lo de las diferentes versiones), manteniendo, eso sí y en lo fundamental, el mismo objetivo: contribuir al desarrollo de la competencia digital de los componentes de los Servicios de Orientación (SEO).

Estoy convencido de que nunca el tiempo es perdido (como dice el poeta), y no como consuelo (quiero creer), sino como resultado de un proceso personal de aprendizaje que sólo las experiencias pasadas han podido hacer posible.

Desde el inicio de este proyecto y hasta el momento actual, han transcurrido ya cuatro años, iniciándose en 2021, muchas entradas y algunos cambios en la forma y la estructuración del contenido.

De todo ello quedan huellas en la actual formulación que mantiene y se basa  en esa historia de tentativas, de modo que la versión actual del blog debe mucho a las anteriores, lo que se manifiesta en los contenidos publicados y en el aprendizaje que implican.

El recorrido realizado, ya en sus primeras formulaciones, se inicia profundizando en las posibilidades de la suite ofimática LibreOffice y muy especialmente en las que ofrece el uso del lenguaje OOo Basic. El mantenimiento del nombre original del blog es un reconocimiento y un tributo tanto a la propia suite y su lenguaje de base, como a esos mismos orígenes.

Mantengo parte del trabajo resultante de esos inicios por considerar que siguen siendo de interés, pero sobre todo porque permanece invariable el análisis de la situación y el objetivo principal que originó esta propuesta: los SEO necesitan una formulación específica de competencia digital, teniendo en ella un espacio propio el conocimiento de lo que puede aportar la ofimática y, dentro de ella, la generación de soportes basados en lenguajes de script, lo que equivale a decir el conocimiento aplicado de la lógica de programación. A esto quiere contribuir este blog.

Partí en los inicios de este proyecto de la constatación de limitaciones en el uso real de medios informáticos por parte de los SEO, pero también de lo insatisfactorio de los planteamiento inespecíficos en la definición de la competencia digital docente por parte de la Administración educativa. 

Respecto a este planteamiento mantengo que es radicalmente insatisfactorio, ya que no tiene en cuenta las especificidades de las necesidades de los SEO. No se explica de otra manera la ausencia de referencia específica a estos servicios ni el olvido de la competencia ofimática como componente principal de su competencia digital.

Además de este "olvido" considero que hay otro que también afecta al conjunto de profesorado: considerar "competencia genérica" el conocimiento de la lógica de programación y mantener la competencia digital docente ajena al pensamiento computacional es un doble error. Por un lado conlleva, en buena lógica y así se confirma, considerar al docente básicamente como un consumidor-usuario de recursos (las hoy llamadas "herramientas de autor"), olvidando la capacidad del docente para crear recursos al margen de lo que proporcionan estas herramientas (1); por otro lado esta consideración resulta contradictoria con la exigencia que se hace al profesorado de ser el facilitador del desarrollo del pensamiento computacional en el alumnado.

Creer que el profesorado dispone de conocimientos y habilidades de pensamiento computacional por haberlas aprendido "genéricamente" resulta, cuanto menos, ajeno a la realidad. Por el contrario, el pensamiento computacional o es aprendido en procesos específicos de formación o su enseñanza (a los alumnos) se tendrá que dejar en manos de especialistas, los profesores de informática, quienes no la han adquirido precisamente por ciencia infusa ni por la mera práctica.

Volviendo a la especificidad de la competencia digital de los SEO, mantenerlos al margen de la lógica de programación acentúa especialmente su condición de meros usuarios, impidiendo que sus componentes sean competentes para generar soluciones que respondan a sus necesidades profesionales. Y dado que este colectivo, por minoritario, no resulta rentable para la industria del software, no cabe esperar que ésta provea de esas soluciones específicas. El resultado es tan previsible como evitable desde otra definición de su competencia digital específica.

Cuanto más competente mejor, evidentemente, pero tampoco es necesario establecer niveles de exigencia elevados. Para obtener resultados tangibles y funcionales es suficiente con incluir en su definición específica de competencia digital los conocimientos necesarios de ofimática creativa.

Entiendo por competencia ofimática creativa un nivel de conocimientos teórico-prácticos (fundamentalmente del segundo tipo) que habilitan al profesional para generar soportes (documentos) basados en los propios servicios ofimáticos incorporando script que faciliten la (semi)automatización de los procesos (2).

Con es nivel como mínimo competencia no estoy estableciendo su techo, pero como primera meta resultaría satisfactoria. A partir de ahí se pueden plantear otras que ahora parecen alejadas de lo posible, pero que en su momento se pueden incorporar como parte de las herramientas que faciliten la práctica profesional. Con ello me refiero, por ejemplo, a tecnologías orientadas al análisis de los datos resultantes de las actuaciones de los SEO. En la medida en que la hoja de cálculo sea o se convierta en herramienta habitual de registro de datos y el análisis de los mismos una práctica frecuente (para el análisis de las actuaciones, por ejemplo), contar con conocimientos informáticos aplicables a estos procedimientos se convertirá en una necesidad.

Pues bien, este blog mantiene su objetivo inicial de contribuir al desarrollo de lo específico la competencia digital de los SEO, incorporando recursos para el desarrollo de la lógica de programación y el conocimiento básico de un sencillo lenguaje de programación (OOo Basic). Conocimiento sistemático de tipo teórico-práctico, no un mero recetario de trucos, pero con claro predominio de esa dimensión práctica que incluye formas de uso, procedimientos de implementación, desarrollo de estrategias de trabajo y propuestas de solución práctica.

NOTAS

(1) No deja de ser revelador al respecto el cambio de denominación que han sufrido estos recursos. Se ha pasado de la denominación lenguajes de autor a herramientas de autor. Este cambio de denominación no es gratuito, ya que conlleva también un cambio de orientación: de basarse en lenguajes de script a ser utilidades que facilitan la generación automática de materiales de aprendizaje y evaluación prêt-à-porter. La aplicación de utilidades IA refuerza aun más esta orientación.

(2) Que no está reñido con el uso de soluciones de terceros, libres o comerciales, ni con la incorporación de recursos basados en la IA.

Evaluación. Ítem.

Ítem de respuesta dicotómica

Dentro de la diversidad de ítem que podemos encontrar en las pruebas de evaluación, uno de los más frecuentes y sencillos es el que requiere del alumno una respuesta (output) verbal aparentemente simple (aunque no lo es tanto) que implica la elección entre dos opciones de tipo V - F o la elección entre dos conceptos igualmente dicotómicos (grande vs. pequeño, igual vs. diferente...).

Este tipo de ítem está representado en pruebas como las de discriminación auditiva en las que se pide indicar si dos estímulos (verbales o gráficos) son iguales o diferentes (1)

En términos de desarrollo de un soporte (o docap) la creación de este tipo de ítem no es muy diferente del ítem de repetición presentado en [esta entrada] por lo que remitiré a ella fin de no reiterar explicaciones ya dadas (2).

En estos ítem el control del soporte lo tiene el OE que emite un input verbal esperando que el alumno responda en función de las dos opciones disponibles, las cuales se presenta, como quedó dicho, en términos dicotómicos. Concretamente en Wepman (3) el OE emite verbalmente un estímulo formado por dos palabras que se diferencian en un fonema y se pide al alumno que diga si ambas son iguales (si es la misma palabra) o diferentes, sin que sea necesario que identifique esa (posible) diferencia.

Este juicio se presenta en términos dicotómicos y exige que el niño haya adquirido ambos conceptos, los cuales, como tales y en su caso, también se han trabajado en presentación dicotómica, como oposición A vs. B.

 

Utilizaré para ejemplificar la creación del soporte dos ítem que ejemplifican las dos opciones de respuesta posibles:

• Igual: LANA-LANA
• Diferente: DEDO - DEBO (oposición /d/-/b/)

También aquí se deberá optar, en primer lugar, entre puntuar directamente el ítem o recoger la respuesta del alumno, dejando para un segundo momento su puntuación, la cual también se hace en términos dicotómicos (A-F; 1-0).

Aunque la opción que parece más apropiada es la puntuación directa, que resulta también la más sencilla de implementar, en caso de optar por trabajar con la respuesta del alumno, podemos plantear dos opciones:

• Registrar la respuesta del alumno mediante dos controles de formulario (comandos) (5) que contienen ambas opciones de respuesta (Igual - Diferente). Dada la delimitación de las respuestas de este tipo de ítem, carece de sentido derivar la puntuación del ítem a un segundo momento puesto que recoger la expresión seleccionada (Igual vs. Diferente) no va a aportar datos adicionales en la fase de análisis de la prueba 
• Registrar la valoración (V/F -> Acierto/Error) que ejecuta previa y directamente el OE una vez escuchada la respuesta del alumno y teniendo en cuenta el criterio establecido de verdad establecido en cada ítem. En este caso también podemos utilizar el control comando, aunque no es la única opción (ver nota 4).

Si analizamos los script OOo Basic podemos comprobar que no existe diferencia entre los distintos modelos de presentación del ítem, dado que estos script trabajan siempre con las puntuaciones del ítem, lo que simplifica la elaboración de un posible docap (5). 

Sub M3Aa

Dim Celda As String

Dim ptos As Integer

Celda = "H22"

ptos = 1

Posicionamiento(Celda,ptos)

End Sub

Esto hace que la subrutina también sea la misma para todos los ítem con independencia del modelo que se siga en su presentación.

Sub Posicionamiento (nCelda As String, p As Integer)

Dim oHoja As Object

Dim oCelda As Object

oHoja = ThisComponent.getSheets().getByName("Weepman3")

oCelda = oHoja.getCellRangeByName(nCelda)

oCelda.setValue(p)

End Sub

Resumiendo el algoritmo podemos decir que mientras que el script entrega a la subrutina los valores celda y puntuación (ptos) (Posicionamiento(Celda,ptos)), ésta se posiciona en la hoja (oHoja = ThisComponent.getSheets().getByName("Weepman3")) como paso previo para posicionarse en la celda (oCelda = oHoja.getCellRangeByName(nCelda)) y traslada a ésta la puntuación establecida en el script (oCelda.setValue(p)).

Documento

El documento [Item2.ods] contiene dos hojas. En la primera (Weepman2) se encuentran los tres modelos de implementación basados en funciones Calc y en la segunda (Weepman3) los mismos modelos basados en OOo Basic. En el IDE del documento puedes encontrar los seis script (recuerda que son ligeras variaciones del expuesto en la entrada) y la subrutina a la que todos ellos llaman (Posicionamiento())

NOTAS

(1) Aunque en esta entrada me voy a centrar en los ítem de entrada (input) verbal, para lo que es el ítem, es indiferente que ésta sea auditivo-verbal que gráfica, ya que lo que importa es que la respuesta esperada del alumno es la emisión de un juicio dicotómico (V-F) o la elección de una de las dos opciones entre dos conceptos presentados en oposición dicotómica (Igual - Diferente), en este caso con independencia de que conceptualmente sean posibles soluciones intermedias (Grande vs. Pequeño)

(2) De hecho la formalización de este ítem se puede considerar una variación del anterior, aunque presenta características específicas que permiten tratarlo de forma diferenciada en la presente entrada.

(3) Test de discriminación auditiva de Weepman. Dado que este test no presenta limitaciones derivadas de autoría crearé un docap sobre el mismo.

(4) También podemos optar por otros controles, pero mantengo el uso del comando frente a botón de opción por similitud con el modelo de output verbal de repetición.

(5) Esto es así por caer en la propiedad Etiqueta del comando el peso de la identificación de la opción válida.

Evaluación. Ítem.

Ítem verbal de repetición

Se trata de un ítem en el que el OE emite una palabra o una frase sencilla y el alumno debe repetirla exactamente igual que la escucha. Por estas características es un ítem apropiado para evaluar las capacidades de perceptivas (audición), las habilidades fonológicas (1) y las de memoria verbal (2).

En cuanto recurso de evaluación se trata de una formulación muy sencilla en requerimientos de presentación del estímulo (input) y de ejecución por parte del alumno (output): la reproducción verbal del modelo dado por el evaluador.

Esta simplicidad también lo es en cuanto a soporte: podemos basarnos en una hoja de cálculo en la que recoger las respuestas o puntuarla directamente de cuerdo con su ajuste al input (3). En todo caso, el control del soporte queda en manos del examinador.

A nivel informático es un tipo de ítem también de formulación sencilla que es posible resolver haciendo uso de funciones Calc, pero también mediante código OOo Basic (4). Expondré en esta entrada ambas formulaciones.

La forma más sencilla de presentación del estímulo es que éste se concrete como una única palabra, pseudopalabra o logotoma (5), aunque en otras formulaciones el input está formado por un conjunto de palabras o incluso por frases. A nivel de informatización del ítem esto carece de importancia.

Como en otros casos, y con independencia de que se aborde el soporte en base a las funciones Calc o mediante código, una diferencia importante en su configuración es la decisión que se tome respecto al modo en que se resuelve la puntuación del ítem: cuando se decide que el examinador (el OE) puntúe directamente la respuesta del alumno, se omite la recogida de la repuesta del sujeto, lo que simplifica la formulación del ítem (y de la prueba).

Esta opción es válida cuando no se considera relevante el análisis de la respuesta dada, sólo que ésta se ajuste o no al modelo (6), pero cuando nos interesa realizar posteriormente un análisis de la producción del alumno, es necesario recogerla (7). En este último caso, partiendo de la respuesta se automatiza la puntuación del ítem.

Como ya dije, la simplicidad del tratamiento informático de este ítem permite que se pueda trabajar únicamente con funciones Calc, posibilidad que ejemplifica la hoja PalMag1. Estas funciones incluso son innecesarias cuando optamos por puntuar directamente la producción del alumno. Cuando recogemos sus respuestas, la puntuación se automatizar mediante la función condicional SI() (=SI(D10="";"";(SI(D10=B10;1;0)))) (8)

En PalMag2 desarrollo la opción OOo Basic. También se presentan dos modelos que se corresponden con los vistos en PalMag1: Puntuación y Respuesta.

En Modelo 1. Puntuación se implementan dos comandos para cada ítem: el primero (cmdMod1Aa) para la puntuación positiva (1) se asocia al script M1Aa y el segundo (cmdMod1Ab) al script M1Ab, y ambos llaman a la subrutina Puntuar() (9). Veamos su código (10):

Sub M1Aa

Dim Celda As String

Dim ptos As Integer

Celda = "C4"

ptos = 1

Puntuar(Celda,ptos)

End Sub

La función del script es concretar los valores de Celda y puntuación (variables Celda y ptos) y pasarlos a la subrutina Puntuar() (Puntuar(Celda,ptos)) que es la que realmente se encarga de realizar el trabajo.

Sub Puntuar (nCelda As String, p As Integer)

Dim oHoja As Object

Dim oCelda As Object

oHoja = ThisComponent.getSheets().getByName("PalMag2")

oCelda = oHoja.getCellRangeByName(nCelda)

oCelda.setValue(p)

End Sub

Esta subrutina cuenta con dos parámetros, en correspondencia con los dos que recibe de los script (Puntuar (nCelda As String, p As Integer)). Como subrutina se encarga de acceder a la hoja (oHoja = ThisComponent.getSheets().getByName("PalMag2")) y a la celda (oCelda = oHoja.getCellRangeByName(nCelda)), por lo que en ella se declaran sendas variables de tipo objeto (oHoja y oCelda), y de posicionar en la celda correspondiente la puntuación entregada por el script en su variable ptos (oCelda.setValue(p))

En Modelo 2. Respuesta el procedimiento es similar, aunque el contenido y el modo de trabajar con los datos es diferente, ya que ahora se recoge la respuesta dada por el alumno y la puntuación de dicha respuesta se deja a cargo de la misma función Calc que vimos en PalMag1, por lo que remito a la explicación anterior (ver también nota 8). Explico a continuación los script de acierto y de fallo de uno de los dos ítem (M2Aa y  M2Ab respectivamente), así como la subrutina a la que ambos llaman (Anotar()) (11)

Sub M2Aa

Dim Celda As String

Dim Respuesta As String

Celda = "D12"

Respuesta = "LLOCABA"

Anotar(Celda,Respuesta)

End Sub

El script V (acierto) es muy parecido a su equivalente en Modelo 1. De hecho, la única diferencia es que la variable de puntuación (tipo Integer) queda sustituida ahora por una variable string, dado que lo que recogemos es la producción del alumno (12)

Sub M2Ab

Dim Celda As String

Dim Respuesta As String

Celda = "D12"

Respuesta = InputBox("Escribe la respuesta dada:")

Anotar(Celda,Respuesta)

End Sub

Por el contrario, el script F (fallo) se plantea de forma diferente a su equivalente en Modelo 1 ya que incluye una instrucción que permite recoger la producción oral del alumno mediante una función InputBox() asociado a la variable Respuesta (Respuesta = InputBox("Escribe la respuesta dada:")) (13). De este modo la subrutina Anotar() escribirá en la celda (D10) el contenido expresado por el alumno.

Sub Anotar (nCelda As String, Rpt As String)

Dim oHoja As Object

Dim oCelda As Object

oHoja = ThisComponent.getSheets().getByName("PalMag2")

oCelda = oHoja.getCellRangeByName(nCelda)

oCelda.setString(Rpt)

End Sub

Esta subrutina (Anotar (nCelda As String, Rpt As String) (14)) es similar a la anterior (Puntuar()) pero se diferencia de ésta por ser su segundo parámetro de tipo String, ya que es de este tipo el dato que entregan los script que hacen uso de ella. La implicación de lo anterior se aprecia en la instrucción que permite pasar ese dato a la celda correspondiente (oCelda.setString(Rpt)): ahora necesitamos emplear el método setString() en sustitución del método anterior (setValue()).

Documento.

En [Item1.ods] puedes encontrar ejemplificados estos dos modelos de trabajo y las dos formas en que se puede manejar el ítem. Para más detalle sobre el código OOo Basic puedes ver los script desde el IDE del documento.

NOTAS

(1) Aunque en las pruebas de evaluación del sistema fonológico se suelen emplear ítem de input visual que elicitan la respuesta del alumno, es perfectamente posible emplear ítem de input verbal, ya que un niño no es capaz de repetir aquellos fonemas o combinación de fonemas que no tiene integrados en su sistema fonológico. De hecho cuando un niño comete un error en tareas de elicitación, suele complementarse el ítem ofreciendo el OE la respuesta correcta de forma verbal.

(2) Se trata de evaluar la memoria verbal inmediata (a corto plazo) y generalmente se incrementa la longitud del input, dando lugar a una tarea que normalmente se denomina de memoria (verbal) secuencial.

(3) En el primer caso (anotar la respuesta) implica dejar a cargo del soporte la puntuación del ítem; en el segundo la puntuación es directa. Recomiendo la grabación digital de las respuestas, especialmente en la primera formulación. También en ella, ahora para puntuar el ítem, podemos emplear funciones Calc o código OOo Basic, como veremos a continuación en el texto de la entrada.

(4) Ver nota 3. Esta simplicidad explica que se hayan construido soportes basados en hojas de cálculo para pruebas que emplean este tipo de ítem sin necesidad de conocimientos de lenguajes de script.

(5) Input formado por una sílaba o serie de sílabas sin significado semántico. Se diferencia de la pseudopalabra en que el logotoma no se basa en una palabra real, aunque comparte con ella la carencia de significado.

(6) Este es el tratamiento más frecuente, debido a que normalmente queda garantizado el cumplimiento del objetivo de la prueba. Además son pocas las circunstancias en las que estaría justificado el trabajo que implica recoger y analizar la producción del alumno. Una de ellas podría ser ahorrarnos la aplicación posterior de una una prueba de evaluación fonológica, aunque se presentan importantes dificultades en la formulación de los estímulos.

(7) Para ello se pueden emplear dos procedimientos que incluso son complementarios: grabar digitalmente el audio de esta producción verbal y/o escribirla directamente. Cuanta mayor sea la longitud de la producción verbal del sujeto evaluado, más justificada está la grabación digital de esta producción, ya que el tiempo que supone su escritura por el evaluador repercute negativamente en el desarrollo de la prueba. Además, las producciones complejas del evaluado incrementan la riqueza (y también la complejidad) del posterior análisis de sus producciones. De hecho, podríamos considerar  que en este caso estaríamos hablando de otro tipo de ítem (y de prueba).

(8) Puedes ver un ejemplo del desarrollo de estos dos modelos o procedimientos en la hoja PalMag1 del soporte Item1.ods. Tanto en C10 como en C11 se aplica la función expresada en el texto de la entrada, pero para acceder a estas celdas deberás desactivar la opción Proteger hoja (Herramientas | Proteger hoja) ya que PalMag1 se encuentra protegida, a excepción de las celdas C4 y C5 (Modelo 1 o de puntuación directa) y D10 y D11 (Modelo 2. Respuesta). En estas dos últimas empleamos, como pudiste ver en la entrada, una estructura condicional anidada: el primer Si() hace que no se muestre puntuación en caso de que las celdas D10 y D11 no tengan contenido; el segundo Si() desarrolla el Else implícito de la primera estructura (esto es: cuando sí conste contenido en D10 y D11), otorgando un punto (1), cuando (por ejemplo) coincida el contenido de B10 y el de D10, esto es: cuando la respuesta del alumno (que anota el OE) coincida con la palabra input expresada por el examinador. De no ser así (Else del segundo condicional) la puntuación es 0.

(9) Los script se encuentran en Module1 y la subrutina en Module3. Ver IDE de Item1.ods.

(10) Muestro el script asociado al comando cmdMod1Aa, que es de puntuación positiva o acierto (1), pero el asociado al comando de fallo (0) (cmdMod1Ab) es básicamente igual, cambiando únicamente el valor de la variable ptos.

(11) Ambos script están asociados respectivamente a los comandos cmdMod2Aa y cmdMod2Ab. Obsérvese que el comando de acierto contiene como etiqueta el nombre de la palabra-input (LLOCABA). Esto es es así para cada una de dichas palabras-Ítem), lo que permite al examinador identificar claramente el ítem que debe puntuar por asociación del comando con la palabra-ítem. El comando fallo se identifica con la etiqueta Otra que remite a una producción output del alumno diferente de la esperada. Dado que el funcionamiento de los script V - F es diferente (algo que no sucede en Modelo 1.Puntuación), ahora, en Modelo 2. Respuesta, se hace necesario explicar ambos script. Los script se encuentran en Module2 y la subrutina asociada en Module3.

(12) Esto conlleva cambios en la subrutina, como veremos después.

(13) En lugar de la función InputBox() podríamos utilizar otros procedimientos, como, por ejemplo, un cuadro de diálogo, pero resulta mucho más complicado en términos de programación. En un docap cuyo control se entrega al alumno esta segunda solución podría considerarse más pertinente, a fin de facilitar su uso por parte del niño, pero en docap que maneja el OE no supone ninguna ventaja significativa, por lo que considero que InputBox() es suficiente para los fines que se pretenden y mucho más sencilla de implementar.

(14) Esta subrutina se encuentra también en Module3

LENGUAJES. OOo Basic

Características de OOo Basic

Cuestiones introductorias

Aunque todos los lenguajes de programación tienen mucho en común, OOo Basic (y también VBA) tiene características específicas que interesa conocer. Este lenguaje procede del desarrollado para OpenOffice y se define como lenguaje de macros. Es fundamental entender lo que implica esta categorización, ya que, aunque la considero poco precisa y hasta cierto punto confusa, resumen lo que OOo Basic tiene de específico (insisto, también VBA): es un lenguaje para trabajar desde dentro de las suites ofimáticas OpenOffice y LibreOffice, desde cada uno de sus servicios (Writer, Calc...), como recurso para automatizar procedimientos.

Dentro de eso que se ha venido en llamar competencia digital docente y más en concreto, en lo referido a la competencia ofimática, el conocimiento (orientado a la práctica) de un lenguaje como OOo Basic nos permite hacer un uso mucho más potente y eficiente de unos recursos que para los Servicios de Orientación (SEO) son fundamentales.

Fundamentales por la propia naturaleza de nuestras funciones y de nuestro trabajo. También por el ahorro de tiempo que supone lo que deriva de ese conocimiento: la posibilidad qu conlleva de automatizar determinados procedimientos y la creación de ciertos documentos. Esto viene a ser equivalente a incremento de la competencia ofimática.

El lenguaje OOo Basic aporta ciertas ventajas, pero también presenta limitaciones que no tienen otros lenguajes de propósito general, no "encerrados" en la suite ofimática (1). Pero ahora me interesa destacar algunas de las innegables ventajas que, en mi opinión, hacen que merezca la pena utilizarlo:

• Usar OOo Basic permite incrementar exponencialmente el aprovechamiento de las suites ofimáticas. Dicho de otra forma, no partimos de cero, y estos conocimientos previos suponen tener andado un buen trecho del camino.
• En relación con lo anterior, los resultados que podemos obtener con OOo Basic son directamente aprovechables desde los propios servicios, con independencia de cuáles sean éstos y de la frecuencia y familiaridad de uso que tengamos de ellos (2)
• Las habilidades que se adquieren con el uso de funcionalidades de cierta complejidad se ven potenciadas con el conocimiento y uso de OOo Basic. La relación entre ambos (funcionalidades avanzadas y creación de script) es bidireccional: ambas se potencian, aunque puedan considerarse alternativas.

Podemos resumir diciendo que OOo Basic, como parte que es de la suite LibreOffice que también es, complementa y potencia sus funcionalidades transformando lo que es un simple documento en una aplicación. Además de permitir automatizar la generación de contenidos, OOo Basic facilita el desarrollo de cierto tipo de análisis de datos.

Las ventajas para el profesional son evidentes: es él mismo quien desde su conocimiento profesional y partiendo de sus necesidades, desarrolla ciertos recursos. Por eso, aunque podemos enmarcar el uso de OOo Basic dentro de la competencia ofimática, en realidad supera ampliamente esta delimitación, ya que se adentra en el conocimiento y uso funcional de las habilidades de programación. Cierto que para ello se requiere conocer el lenguaje.

NOTAS
¹ Me refiero, por ejemplo, a Python, lenguaje del que trataremos más adelante.
² Constato reiteradamente que la frecuencia de uso, por si misma, no permite incrementar el nivel de conocimiento que se tiene de ellos. Y lo que es igualmente limitante: los servicios realmente utilizados son el procesador de texto y, muy en segundo lugar, de los servicios de creación de presentaciones. Las hojas de cálculo y no digamos las bases de datos son poco conocidos en la práctica. Considero que esto evidencia la insuficiencia de considerar que el uso genera por si mismo un incremento conocimiento de las funcionalidades de las herramientas y consecuentemente su mejor aprovechamiento. Siendo esto así, se hace aun más necesaria una formación específica sobre dichas funcionalidades, incluyendo la propia y específica sobre los "lenguajes de macros".