Informes sobre el uso de plataformas

Según el informe realizado por Delta Initiative en colaboración con la California State University, sobre la evolución y los sistemas escogidos por los centros educativos, queda clara la hegemonía de Blackboard 9 sobre las soluciones open source. No obstante, si analizamos la evolución en los últimos años, veremos cómo Blackboard ha ido perdiendo cuota de mercado paulatinamente, en favor de soluciones open source como Sakai o Moodle.

Esto contribuye al debate sobre si, realmente, el open source tiene tantas ventajas. Si las tuviera, ¿no creéis que las universidades lo utilizarían en masa? Dejo aquí la pregunta.

Ranking de herramientas más utilizadas para el aprendizaje

Recientemente, he descubierto un ranking de herramientas de aprendizaje realizado por Jane Hart cuyo sitio web han recomendado en la lista de distribución de e-learning de Red Iris y al que podéis acceder en http://www.c4lpt.co.uk/ReadingLists/index.html. El ranking yo lo he encontrado en http://www.c4lpt.co.uk/recommended/.

Dentro de esta clasificación, el único LMS que aparece es Moodle (en el puesto 14). Una cosa que me llama la atención es que hace referencia a herramientas de características muy dispares por lo que no acabo de entender qué criterios se han seguido para realizar este ranking.

A la hora de seleccionar una plataforma, yo os recomiendo la página web de EduTools. A mí me resultó muy útil hace tiempo cuando tuve que hacer una comparativa entre plataformas. En esta web, puedes especificar los requisitos que necesitas y te recomienda una serie de plataformas ordenadas por los requisitos introducidos. Suele estar actualizada y los organismos encargados de gestionar los LMS (al menos la Sakai Foundation sí que lo hace) envían información que ellos contrastan.

Un estudio muy interesante pero que no es un ranking en el sentido de comparativa, es el llevado a cabo por investigadores de la Universidad Murcia y cuyo objetivo es establecer qué LMS se utilizan en las Universidades Españolas. Os recomiendo que lo leáis.

¿Alguien conoce otros rankings? ¿Qué os parece si hacemos un ranking en este blog?

Encuentro de Spanish Sakai en Pamplona

Los días 19 y 20 del pasado mes de noviembre tuvo lugar en Pamplona el encuentro anual de universidades españolas que utilizan Sakai, con una acogida muy buena.
Os dejo aquí una de mis ponencias titulada, como no podía ser de otra manera, Moodle vs Sakai.
En la presentación encontraréis una comparativa entre ambas plataformas desde los puntos de vista de la instalación y configuración, las funcionalidades más habituales en un curso on-line y algunos otros aspectos tales como la internacionalización, el desarrollo de herramientas o la usabilidad.

Medida de prestaciones (y III). Script JMeter para Moodle

Éste script, en su versión actual, es más sencillo que el disponible para Sakai en una entrada anterior. Espero ir mejorando el script con el tiempo. Os mantendré informados en esta entrada.

Educase 2009 - "Blackboard, Moodle & Sakai"

Una de las conferencias más importantes del sector, Educase tuvo lugar durante la primera semana de noviembre. Os recomiendo que visitéis la página porque puede encontrarse información muy interesante.

Entre las ponencias, hubo una en la que representantes de Blackboard, Moodle y Sakai discutieron sobre los pros y los contras de adoptar soluciones propietarias frente a las soluciones open-source, comparando aspectos tales como el coste, licencias, opciones de hosting y soporte técnico, etc. En el siguiente enlace podéis descargaros el vídeo y las transparencias.

Como podréis comprobar, repiten muchas de las ideas que ya hemos comentado en alguna entrada anterior. Eso es buena señal, ¿eh?

Medida de prestaciones (II). Script JMeter para Sakai

El script Sakai.jmx incluye las herramientas más comunes en un site de Sakai, aunque no todas. De todos modos, si observáis, el incluir una nueva en el script es bastante sencillo.
Os resumo algunos puntos importantes a la hora de utilizar este script:

• Está generado con la versión 2.3.4 de JMeter, por lo que está garantizado el funcionamiento para versiones anteriores.


• El scriptdir es el directorio en donde vais a guardar los ficheros a los que accederá JMeter. En este directorio se guardan los ficheros de usuarios (users_list.txt) y de contraseñas (pwd_list.txt). Para cada hilo de ejecución, JMeter extraerá un usuario y una contraseña de este fichero e intentará identificarse con esas credenciales.


• No os olvidéis de configurar la dirección IP/nombre DNS del servidor, el puerto por el que recibe las peticiones así como el protocolo (HTTP/HTTPS) que está configurado.


• Otro aspecto importante de este script es que debéis aseguraros de que los usuarios tienen configurado en sus preferencias de idioma, el mismo en el que especifiquéis los nombres de las herramientas en la sección “set variables”. En caso contrario, los patrones de extracción de las expresiones regulares no funcionarán y, por tanto, las partes del scripts implicadas tampoco.

Por favor, si alguien lo utiliza, le ruego que me envíe la configuración de su plataforma tecnológica y los resultados obtenidos con el script, con el fin de recopilar las experiencias y de que nos beneficiemos todos.

Medida de prestaciones (I)

En esta entrada aprenderemos algunos conceptos básicos de medidas de prestaciones utilizando la herramienta JMeter. En próximas semanas veremos cómo hacer un script básico con esta herramienta para Sakai y para Moodle.
Conceptos básicos sobre medida de prestaciones
El objetivo de las medidas de prestaciones es intentar predecir anticipadamente problemas de rendimiento y degradación de recursos del sistema antes de su paso a producción y facilitar su corrección. Dicho de manera muy simple resumida: se trata de encontrar la carga para la cual el tiempo de respuesta se dispara, es decir, se degradan las prestaciones del sistema.

Así pues, la utilidad de las medidas de prestaciones es tener una estimación de cómo se comportará el sistema en un entorno real bajo unas circunstancias dadas con el fin de, por ejemplo, ser capaces de dimensionar adecuadamente la plataforma. En definitiva, se persigue, por una parte, evaluar la entrega (¿cumple con lo que espera el cliente?; ¿Cómo se estima que funcione la aplicación en producción?) y, por otra, evaluar la infraestructura elegida (¿es adecuada para la capacidad que va a soportar?¿se producen cuellos de botella?
Un aspecto crítico para el éxito de las pruebas de prestaciones es tener claro qué se quiere medir y definir las baterías de pruebas más adecuadas para ello.
¿Qué es Jmeter?
Apache JMeter es una herramienta para realizar pruebas de rendimiento y pruebas funcionales sobre aplicaciones web en general. Es desarrollada por la ASF (Apache Software Foundation).
El Apache JMeter está diseñado para desarrollar diferentes tipos de test; permitiendo diseñar tanto sencillos teses que soliciten simples páginas web, como complejas secuencias de requisiciones que permitan evaluar el comportamiento de una aplicación o como la capacidad de carga máxima que pueda tener una aplicación en un servidor (pudiendo llegar a satura el servidor).
JMeter también permite la ejecución de pruebas distribuidas entre distintos ordenadores, para realizar pruebas de rendimiento.
El Apache JMeter incluye una interfaz gráfica de usuario que facilita el diseño de las pruebas. Esta interfaz gráfico además de aportar un entorno cómodo de trabajo, también permite guardar y alterar tanto los test desarrollados como los componentes que lo integran. Gracias a esto se pueden reutilizar las pruebas o módulos de las mismas en el desarrollo de nuevas pruebas.
Además, Apache JMeter también ofrece la posibilidad de activar un Proxy web, por lo que se puede grabar la navegación de un usuario para posteriormente usarla en la generación de una prueba.
Conceptos básicos
A continuación se ofrece una descripción muy resumida de los conceptos básicos que deben conocerse para trabajar con JMeter. Para un mayor nivel de detalle, remitimos al lector a la documentación de referencia.

• ThreadGroup:
  
  
  
  • Es el punto de inicio de cualquier plan de pruebas. Todos los controles y samplers deben estar debajo del ThreadGroup. Otros elementos, como Listeners, pueden estar en la misma jerarquía.
    
    • Controla el numero de threads (Usuarios virtuales) que se usaran en la ejecución de las pruebas. Las opciones que tiene son:
      
      • Number of threads: número de usuarios. Cada thread ejecuta el plan de pruebas entero de forma independiente.
      
      
      • Ramp-up Period: Le indica a Jmeter el periodo de tiempo en que se llegará al nuúmero total de usuarios. Si son usados 10 threads y el ramp-up es de 100 seg, entonces Jmeter se tomará 100 segundos para crear y correr los 10 threads. Cada thread será creado 10 seg (100/10) después de la creación del Thread anterior.
      
      
      • Loop Count: Cantidad de veces que se correrá el plan de pruebas.
      
      
      • Scheduler: Brinda mas opciones a la ejecución de las pruebas. Podemos agregar la hora de comienzo y la hora de fin, los campos Duración y Delay reemplazan a los dos anteriores.
      
      


• Samplers:
  
  
  
  • Indica cómo mandar las peticiones al servidor. Cada sampler tiene características diferentes y puede mejorarse agregando elementos de configuración (Configuration Elements ).
  
  
  • Los tipos de samplers son:
    
    
    
    • Controladores Lógicos: permiten configurar la lógica que Jmeter usa para decidir cuándo mandar una petición.
    
    
    • Los controladores lógicos son:
      
      
      
      • Timers: por defecto, los Thread de Jmeter mandan las peticiones continuamente. El agregado de timers dan la posibilidad de especificar el ‘Think Time’ para que las pruebas sean más reales. Hay diferentes tipos según la necesidad del escenario de pruebas.
      
      
      • Assertions: permiten validar hechos (sucesos) acerca de las respuestas del servidor en la ejecución de las pruebas. Usando assertions se puede ‘testear’ que la aplicación está funcionando correctamente, recibiendo las respuestas esperadas del servidor. Pueden ser agregados a cualquier sampler.
      
      
      • Configuration Elements: trabajan junto a los samplers. Si bien no mandan pedidos, pueden agregar a o modificar los pedidos. Los más usados son HTTP Cookie Manager, HTTP Request Default, User Defined Variables estre otras.
      
      
      • Pre-Processor Element: ejecutan acciones antes que un sampler realice un pedido. Comúnmente es utilizado para modificar la configuración del sampler justo antas que se ejecute o para actualizar variables que no son extraídas del texto de respuesta.
      
      
      • Post-Processor Element: ejecutan acciones después que un sampler realice un pedido. Comúnmente es utilizado para procesar los datos de respuesta o extraer información de ésta.
      
      
  
  Orden de Ejecución
  Los componentes de Jmeter se ejecutan con el siguiente orden de prioridad:
  
  
  
  1. Configuration elements
  
  
  2. Pre-Processors
  
  
  3. Timers
  
  
  4. Sampler
  
  
  5. Post-Processors
  
  
  6. Assertions
  
  
  7. Listeners
  
  
  
  Con estos conceptos básicos y el manual de referencia del JMeter, ya estamos en condiciones de empezar a hacer pruebas.
  En entradas sucesivas, estudiaremos un plan de pruebas para Sakai y para Moodle. Por supuesto, si alguno de vosotros tiene ya algún script hecho y quiere que lo comentemos, solamente tiene que adjuntarlo.

Internacionalización (y III). Moodle.

En Moodle la corrección de los errores de internacionalización es mucho más sencilla, ya que se puede hacer directamente desde Moodle como administrador y que, además, habitualmente se trata de literales que no se encuentran en los ficheros de recursos (o, como se prefiere en la terminología Moodle, paquetes de idioma).
El primer paso es instalar el o los paquetes de idiomas que nos interesen y, desde la administración del sitio, seleccionar la opción de edición del idioma, indicando con el que vamos a trabajar. La figura muestra un ejemplo para el idioma Español:

Una vez aquí, nos interesará saber qué literales están sin traducir. Para ello, seleccionaremos la opción de Revisar las cadenas (strings) perdidas, lo que nos llevará a la siguiente pantalla:

Y ahora viene en donde, en mi opinión, Moodle es superior a Sakai. Llega la hora de poner solución a las cadenas perdidas. Para ello, hay que ir a la opción de Editar palabras o frases y seleccionar, para los idiomas de interés, el módulo/bloque/actividad de Moodle que se quiera revisar. Automáticamente, aparece en pantalla un formulario en el que se muestran la frase original (en inglés) y una caja de texto en donde se nos pida que introduzcamos la traducción en el idioma deseado. La figura aclara estos conceptos:

Con los ficheros de ayuda, ocurre exactamente lo mismo. Desde el propio Moodle, el administrador puede traducir los ficheros para cada bloque/actividad y para cada idioma:

Como vemos, cuando el problema es que faltan literales en los paquetes de idiomas, en Moodle resulta mucho más sencillo cambiarlos que en Sakai. Sin embargo, si el error fuera que el texto está fijo en el código fuente, habría que parametrizarlo de manera muy similar.
En primer lugar, tendríamos que incluir el literal en los ficheros de los paquetes de idiomas. Para ello, abrimos el fichero de un módulo correspondiente al idioma por defecto (el inglés) e incluimos una nueva entrada. Por ejemplo, supongamos que hemos creado un bloque propio de nombre mibloque. Tendríamos que tener un fichero {moodle.root}/blocks/mibloque/lang/en_utf8/block_mibloque.php en el que incluyeran todas las cadenas que se muestran al usuario con el formato

$string['micadenadetexto'] = 'Aquí va el texto';

Una vez incluida esta entrada, cuando queramos mostrar al usuario esa cadena, debemos utilizar el siguiente código:

<?php print_string('micadenadetexto', 'block_mibloque'); ?>

Internacionalización (II). Sakai

En esta entrada vamos a ver con cierto detalle cómo internacionalizar una herramienta en Sakai. Podréis encontrar más información en la web de i18n de Sakai o la de Spanish Sakai, cuya visita os recomiendo.

Antes de empezar
Java proporciona utilidades estándar empleadas para cambiar el formato de número, de las fechas, etc. Siempre que sea posible, se usarán estas clases. En el tutorial sobre i18n que hay la web de Sun encontramos se explican estos aspectos con cierto nivel de detalle.

Los ficheros de recursos
Como dijimos en la entrada anterior, entenderemos por ficheros de recursos de internacionalización (de ahora en adelantate, solamente recursos) como aquellos ficheros que contienen los mensajes que se muestran al usuario y cuyo contenido varía dinámicamente en función de la información de contexto (habitualmente, el idioma seleccionado por dicho usuario). En el caso de Sakai, estos ficheros reciben la denominación genérica de location bundles y físicamente se corresponden con ficheros de texto con el formato nombre_etiqueta=valor guardados con la extensión .properties.

Un aspecto importante es el del orden. Tan sólo en una herramienta de Sakai pueden llega a haber varios cientos de literales y si no los organizamos con cierto criterio, estos ficheros pueden llegar a hacerse verdaderamente inmanejables. Un ejemplo de organización es el de la figura siguiente:

page.message.key = This is a message will be shown in page "page"

Es decir, el nombre del literal ofrece una referencia de la página a la que pertenece (page), del contenido del mensaje (message) y, por ejemplo, de la acción para la que sirve (key).

Otro aspecto importante relacionado con los ficheros de recursos es que no es necesario (ni recomendable) dividir una sola frase en varios literales únicamente porque algunas partes de dicha frase es variable, bien porque contiene parámetros, o bien para adarpar su estructura a la construcción gramatical de sujeto/verbo/objeto en los diferentes idiomas. Puede y debe dejarse todo en el mismo literal y construir el mensaje apropiado en cada idioma utilizando el método getFormattedMessage de org.sakaiproject.util.ResourceLoader.

Aclararemos este último punto con un ejemplo. Supongamos que el mensaje que queremos mostrar por pantalla un saludo personalizado para cada usuario:

Bienvenido a Sakai, David. Esperamos que disfrutes la experiencia.

El modo erróneo de hacerlo, sería

page.statement.1 = Bienvenido a Sakai,
page.statement.2 = . Esperamos que disfrutes la experiencia

En su lugar, el literal correcto sería:

page.statement.1 = Bienvenido a Sakai, {0}. Esperamos que disfrutes la experiencia

La clase ResourceLoader
Sakai proporciona una clase, org.sakaiproject.util.java.ResourceLoader, que actúa de envoltorio (wrapper) de java.util.ResourceBundle y que selecciona el Locale (idioma) con el que se cargan los ficheros de recursos según la siguiente orden:

1. Preferencias de idioma del usuario


2. Sesión del usuario


3. Configuración del sistema (JVM)

El ResourceLoader se ubica en kernel-util de Sakai. Por ello, todas las herramientas que lo utilicen deben incluir en el lugar adecuado de su pom.xml la siguiente dependencia:

<dependency>
<groupId>org.sakaiproject.kernel</groupId>
<artifactId>sakai-kernel-util</artifactId>
</dependency>

Una vez hecho esto, cualquier literal podrá ser obtenido del fichero de recursos con el siguiente código JAVA:

ResourceLoader rl = new ResourceLoader("ruta_al_fichero_de_recursos");
String foo = rb.getString("page.statement.1");

Errores debidos a que faltan literales
En http://qa1-nl.sakaiproject.org/international/ está registrado cuál es el estado de traducción de ficheros de properties para distintas versiones de Sakai.
Generalmente, cuando nos encontramos un mensaje en inglés (el idioma por defecto), es porque el mensaje en cuestión no tiene literal asociado en el fichero de properties del idioma seleccionado. Cuando esto ocurre, Sakai carga el fichero en inglés y busca la clave en él.
Si éste es el caso, únicamente hay que copiar la línea del mensaje en inglés y traducir el mensaje al idioma deseado, dejando invariable eso sí, la clave.
Corrección de errores en una JSP/JSF
Una vez que está incluida la dependencia respecto de ResourceLoader, el paso siguiente es utilizar esta clase correctamente.
Una alternativa es cargar el fichero de recursos en el faces-config.xml de la herramienta como si se tratase de un bean más:

<managed-bean>
<description>
Dynamic Resource Bundle Loader
</description>
<managed-bean-name>msgs</managed-bean-name>
<managed-bean-class>org.sakaiproject.util.java.ResourceLoader</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
<managed-property>
<description>Bundle baseName</description>
<property-name>baseName</property-name>
<value>ruta_al_fichero_de_properties</value>
</managed-property>
</managed-bean>

Otra opción es incluir el bean directamente en la página JSP/JSF:

<jsp:useBean id="msgs" class="org.sakaiproject.util.ResourceLoader" scope="session">
<jsp:setProperty name="msgs" property="baseName" value="_org.sakaiproject.tool.foobar.bundle.Messages_"/>
</jsp:useBean>

Ahora supongamos que encontramos un error de internacionalización consistente en que siempre se muestra el mismo mensaje en pantalla, independientemente del idioma activo (es el más común). Seguramente, será porque en la página JSP/JSF que muestra el mensaje, encontraremos un fragmento de código similar a éste:

<h:outputText value="This is an English text">

Lo primero es detectar la JSP/JSF en la que está texto fijo y llevar este texto a los ficheros de properties, por ejemplo, paquete.de.mi.herramienta.Messages_xx:

• Messages.properties -> sample_text = This is an English text


• Messages_es.properties -> sample_text = Éste es un texto en inglés

Cuando lo hayamos hecho, solamente habrá que invocar al bean que haga referencia al ResourceLoader.
Corrección de errores en una VM
En las Velocity Templates, el proceso es muy similar alterior, salvo por el hecho de que ResourceLoader, en lugar de cargarlo en un fichero de configuración (faces-config.xml) o directamente en la página (con la directiva jsp:useBean), se carga en el contexto de la plantilla:

ResourceLoader rb = new ResourceLoader("ruta_al_fichero_de_properties");
context.put("tlang", rb );

Para, posteriormente, poder hacer referencia al mismo de las páginas vm:

$tlang.getString("page.sentence.1");

Corrección de errores en el código JAVA

Cuando el literal se encuentra inmerso en el código JAVA, el proceso es algo más complejo.
El primero paso será detectar en qué clase JAVA se encuentra el gazapo. Para ello, podemos utilizar cualquier herramienta que busque en el contenido de un fichero.
Seguidamente, habrá que incluir en el mensaje en los ficheros de recursos correspondientes.
Hecho esto, nos quedan dos cosas:

1. Cargar dinámicamente el fichero de recursos en función de las preferencias de idioma del usuario. Esto se consigue importando la clase org.sakaiproject.util.ResourceLoader e indicando el fichero de recursos.
   


2. Construir el mensaje con la cadena obtenida por el ResourceLoader.
   

Llegados a este punto, si desplegamos y volvemos a la herramienta veremos que se ha solucionado.
Os propongo que detectéis uno error de este tipo y lo intentéis solucionar. Yo estaré encantado de asistiros en el proceso. Tan sólo tenéis que preguntar. Eso sí, os pediría que, por favor, si encontráis algún error, lo indiquéis en el JIRA, el sistema de bugtracking de Sakai.

Internacionalización (I). Problemas.

La internacionalización, también llamada i18n, según la Wikipedia puede definirse como "el proceso de diseñar software de manera tal que pueda adaptarse a diferentes idiomas y regiones sin la necesidad de realizar cambios de ingeniería ni en el código". Se trata de un concepto muy amplio que abarca desde ser capaz de modificar dinámicamente los mensajes mostrados al usuario (por defecto, suelen estar en inglés) hasta mostrar la interfaz construida de derecha a izquierda como ocurre en los países árabes, pasando por tener en cuenta las costumbres regionales a la hora de presentar los iconos, por ejemplo.
Como dijimos al hablar de los criterios de selección de plataformas, la i18n es uno de los fundamentales sobre en todo países o regiones con diversidad lingüística en donde se dispone de varios idiomas oficiales. Si éste es el caso, una vez seleccionadas las herramientas que se pondrán a disposición de los usuarios, resulta imprescindible probarlas concienzudamente en los idiomas requeridos, haciendo especial hincapié en los problemas de internacionalización más comunes y que, a modo de resumen, son los siguientes:

1. Mensajes de la interfaz de usuario: lo habitual es que los mensajes mostrados en la interfaz de usuario estén contenidos en ficheros de texto, tal y como ocurre en Moodle (paquetes de idiomas) y en Sakai (ficheros de properties). Sin embargo, puede ocurrir que nos encontremos con alguna herramienta en la que aparecen en inglés independientemente del idioma seleccionado. Esto, generalmente, se debe a alguno de los dos siguientes errores de i18n:
   
   • El mensaje en cuestión es incluido "tal cual" en el código fuente: en este caso, habrá que editar el código fuente y parametrizarlo adecuadamente, incluyendo el mensaje problemático y su correspondiente traducción en un paquete de idioma (caso de Moodle) o en un fichero de properties (caso de Sakai)
   
   
   • El mensaje está el fichero de recursos en inglés pero no en el del idioma seleccionado: la solución es muy sencilla y consiste en incluir la traducción del mensaje en el fichero del idioma seleccionado.
   
   


2. Las listas de nombres (por ejemplo, alumnos) no se ordenan correctamente: desgraciadamente, éste es uno de los problemas más comunes. Se debe a las diferencias en el esquema de codificación esperado por la plataforma. Por este motivo, se recomienda utilizar UTF-8, juego de caracteres que contiene todos los símbolos de nuestro entorno.


3. Formato de los calendarios: el día considerado como comienzo de la semana varía de unos países a otros. Por ejemplo, en España se considera que la semana comienza en Lunes mientras que en los países de habla sajona, convierten al domingo en su primer día semanal.
   En esta misma línea conviene revisar el formato de fechas, ya que algunas aplicaciones fallar con formatos de fechas diferentes del que tienen por defecto. La solución pasa por parametrizar el formato de las fechas y, en caso de no ser posible, por hacer una conversión del formato del usuario al formato con el que trabaja la herramienta.


4. Formato de los números:hay que tener cuidado con la separación entre la parte entera y la parte decimal. Mientras que en España se emplea la coma como separador, en los países sajones se utiliza el punto. La solución es formatear los números en función del idioma seleccionado o bien incluyéndolo como un parámetro más de la instalación.


5. Información de estado: este tipo de información debe ser independiente del idioma. Si no lo fuera, podría ocurrir, por ejemplo, que un mensaje de un foro apareciera en la carpeta de mensajes "Received" cuando se está visualizando en inglés pero no lo hiciera en la carpeta "Recibidos" al verlo en español. La solución suele ser almacenar en base de datos un código de estado y mostrar por pantalla una descripción del mismo consultando los ficheros de properties o los paquetes de idiomas correspondientes.


6. Aplicaciones que están internacionalizadas pero toman el idioma del navegador o del servidor de aplicaciones y no permiten al usuario modificarlo dinámicamente: como ejemplo, algunas aplicaciones de Sakai basadas en Spring (algunas páginas de Samigo, por ejemplo) usan el idioma del Tomcat. E internet está lleno de formularios web que toman el del navegador (contribución de Daniel Merino Echeverría).
   

En la próxima entrada aprenderemos a comprobar el estado de la internacionalización en Sakai y en Moodle. Nos vemos la semana que viene.

Selección de plataformas

Una vez que ya está claro que la organización quiere instalar una plataformas de e-learning, el paso siguiente es encontrar cuál y, a ser posible no equivocarse. :)

La gama de plataformas que tenemos es enorme pero, no nos engañemos, solo podemos evaluar, con suerte, unas pocas. Para seleccionarlas conviene seguir un proceso ordenado que, a grandes rasgos, está esquematizado en la figura siguiente:

Obviamente, probarlas todas resulta inviable por lo que es necesario realizar una criba inicial resultado de una selección gruesa. Los criterios empleados en esta selección gruesa tienen un carácter general, como la documentación existente sobre la misma (aspecto éste muy importante, sobre todo si se trata de una plataforma open source), si está funcionando en alguna institución del entorno, información obtenida de revistas (A-HEC) o páginas web especializadas (GATE o Edutools), etc. En cualquier caso, el resultado será un número reducido de plataformas (2 o 3, como mucho) que se someterán a una selección fina que reducirá, todavía más, este conjunto. En este caso, los criterios de selección son mucho más específicos de la institución: arquitectura tecnológica, bases de datos, crierios pedagógicos, etc. El objetivo es quedarse con una o dos plataformas que serán las que se instalará y probarán y de entre las cuales se seleccionará la plataforma elegida.

En cuanto a los criterios de selección fina, en mi opinión, no hay que olvidar:

• Internacionalización: es la capacidad de la plataforma para "hablar" varios idiomas de manera indistinta. Hay que comprobar que el LMS que se seleccione incluya soporte total para los idiomas que nos interesa en las herramientas que nos interesa. No hay que dejarse guiar por frases como "Moodle (o Sakai) soportan más de N idiomas". Eso es falso, porque el soporte no es completo. Sería un error escoger una solamente porque el valor añadido que ofrece es que tiene un módulo que no utilizo en un idioma que no me interesa. Por ello, resulta crítico probar las plataformas en los idiomas que se vayan a utilizar y probarlas a fondo.


• Integración con otras aplicaciones: a menudo, sobre todo si trata de una organización relativamente grande (como es el caso de una universidad), la plataforma de e-learning debe integrarse con otras aplicaciones (intranet, matriculación, ERP, etc.). Este punto es crítico puesto que una mala decisión puede complicarnos la vidad en un futuro.


• Operación y mantenimiento: las plataformas de e-learning, para que funcionen correcdtamente, hay que mantenerlas esto es, habrá que diseñar mecanismos de back-up, de seguridad, etc.


• Formación del personal: si el personal técnico de la organización no sabe JAVA, conviene seleccionar Moodle o importir formación sobre JAVA EE avanzado a dicho personal. Igualmente, si nuestros técnicos no saben PHP, Sakai es la mejor solución en este aspecto.


• Evolución de las plataformas: no todas evolucionan a la misma velocidad y con el mismo cuidado. No hemos de olvidar que el mercado del e-learnig está floreciendo y por ello, cada día aparecen nuevas herramientas que se presentan como útiles para el proceso de formación (podcast, videoconferencia, blogs, wikis, etc.). De igual modo, resulta interesante saber cómo de activa es la comunidad de usuarios de cada una de las plataformas, especialmente si se trata de aplicaciones de código abierto, como es el caso de Sakai y Moodle (contribución de J. Cristóbal Barrios).

Una vez que ya se dispone de las plataformas candidatas, el paso siguiente es montar un piloto, lo más parecido posible al entorno real y hacer pruebas de todo tipo para evitar llevarnos sorpresas desagradables.