pautas recomendadas producción

PAUTAS DE PRODUCCIÓN

ÍNDICE1. REQUISITOS PREVIOS2. PROYECTOS RED.ES3. EMPAQUETADO4. CATALOGACIÓN5. TRAZABILIDAD6. ENTREGA7. CONTACTOS/DUDAS

ANEXOS:– EJEMPLO EMPAQUETADO OA– EJEMPLO EMPAQUETADO SD– EJEMPLO CATALOGACIÓN– MODELO DE DATOS DEL RUN-TIME

DOCUMENTACIÓN

1. REQUISITOS PREVIOS

Para seguir el contenido de estas transparencias es necesario conocer y saber utilizar las especificaciones:

–Perfil de aplicación LOM-ES.

–SCORM 2004 (IMS Content Packaging, IMS Simple Sequencing , API de JavaScript de SCORM 2004).–Taxonomías y tesauros: ETB, Árbol Curricular, Nivel Educativo, Accesibilidad, Disciplina y Competencia.

1. REQUISITOS PREVIOS

Para seguir el contenido de estas transparencias es necesario disponer de:

–Ultima versión de Agrega Offline: http://redes.agrega.indra.es/visualizadorcontenidos/Descargas/Descargas.do–Rustici: http://www.scorm.com/

–RTE ADL: http://www.adlnet.gov/downloads/downloadPage.aspx?id=280

2. PROYECTOS RED.ES• Los proyectos de creación de contenidos

se caracterizan por:– Paquetes SCORM 2004 con trazabilidad de

los contenidos.– Etiquetado LOM-ES– Secuenciación guiada basada en IMS SS– Otros tipos de secuenciación implementada

en los propios contenidos.– Multilingües: Castellano, Catalán, Euskera,

Gallego, Valenciano e Inglés

2. PROYECTOS RED.ES

– Unidades de producción : Secuencias Didácticas(SD) y Objetos de Aprendizaje(OA).

– Cada unidad de producción se replica para cada idioma distinto. Así para una SD formada por 5 OA, se van a crear 36 unidades de producción: 6 únidades en castellano, 6 en catalán, 6 en euskera, 6 en gallego, 6 en valenciano y 6 en inglés.

– Ejecución de los paquetes en entornos LMS y entornos web fuera de un LMS.

2. PROYECTOS RED.ES

– La producción de las unidades se realiza de la siguiente forma:

Generación OAS

Generación SD

Idioma Castellano

….

Generación OAS

Generación SD

Idioma Inglés

2. PROYECTOS RED.ES

– Se fija un idioma(en general se partirásiempre del castellano).

– Se crean los OAs necesarios para crear una SD.

– Se crea la SD a partir de los OAs creados en el paso anterior.

– Se vuelve a empezar el ciclo para generar los Oas y la SD en el siguiente idioma, aprovechando los contenidos generados en el paso anterior.

– Repetir el proceso por cada SD necesaria.

3. EMPAQUETADO• Elementos de partida.

– Contenidos binarios.– Ficha Instruccional.– Archivo Escenario.html– Otros aspectos de diseño y estilo proporcionados

por Red.es– Agrega Offline

• Producto que se genera.Paquete SCORM 2004

• Herramienta de creación.Agrega Offline

• Ciclo de vida:

Recursos

Objetos Aprendizaje

Crear organización Etiquetado Empaquetado

Archivos

3. EMPAQUETADO

Tipos de paquetes que se van a generar:– Objetos de aprendizaje (OA)

Definición : Paquete formado por una única organización que dispone de un único item que referencia a un único recurso.

– Secuencia didáctica(SD)Definición : Paquete formado por una única

organización que dispone de una estructura jerárquica de items que pueden hacer referencia a submanifiestos o bien a recursos.

3. EMPAQUETADO

• La SD con los OA’s como conceptos

• Pautas en http://www.proyectoagrega.es/docs/guias_produccion/714_Manual_Referencia_y_estilo_grafico_V07.pdf

3. EMPAQUETADO

• El empaquetado de un OA requiere realizar las siguientes actividades:– Subir los contenidos binarios que se van a

empaquetar a Agrega Offline.– Convertir los contenidos binarios subidos en un

recurso.– Crear un organization con un único item, y

referenciar el recurso desde el mismo.– Etiquetar el paquete a nivel de organization, y si

fuera necesario a nivel de item para la secuenciación guiada.

– Validad, previsualizar y guardar como un archivo .zip

3. EMPAQUETADO

UPLOAD CONTENIDOS

BINARIOS

CREACIÓNRECURSO

CREACIÓN ORGANIZATION

ASOCIAR RECURSO A

ITEM

INSERTAR METADATOS

INSERTAR SECUENCIACIÓN

GUIADA

VALIDAR , PREVISUALIZAR

Y GUARDAR .ZIP

El ciclo de vida del empaquetado de un OA es:

3. EMPAQUETADO

• El empaquetado de una SD requiere realizar las siguientes actividades:– Subir a Agrega Offline los paquetes SCORM 2004 que

van actuar como submanifiestos del paquete que se estácreando.

– Subir a Agrega Offline el contenido binario que no se encuentra en los paquetes que actúan como submanifiestos, y que formará parte del paquete que se está creando en forma de recurso.

– Convertir los contenidos binarios subidos en recursos.– Crear un organization con la estructura jerárquica de items

que sea necesaria, y referenciar desde los mismos los recursos y submanifiestos.

– Etiquetar el paquete a nivel de organization, y si fuera necesario a nivel de item para la secuenciación guiada.

– Validad, previsualizar y guardar como un archivo .zip

3. EMPAQUETADO

CREACIÓN PAQUETESCONTENIDO

CREACIÓN PAQUETE

CONTENEDOR

El proceso de creación de una SD consta de 2 fases:

3. EMPAQUETADO

UPLOAD CONTENIDOS BINARIOS Y

SUBMANIFIESTOS

CREACIÓNRECURSOS

CREACIÓN ORGANIZATION

ASOCIAR RECURSOS Y SUBMANIFIESTOS A ITEMS

INSERTAR METADATOSINSERTAR SECUENCIACIÓN

GUIADA

VALIDAR , PREVISUALIZAR Y GUARDAR .ZIP

El ciclo de vida del empaquetado de una SD es:

3. EMPAQUETADO

• Algunos puntos a tener en cuenta:– Si un paquete requiere secuenciación

condicionada, está deberá estar implementada en el contenido binario. ¡¡NUNCA SE USARÁ IMS SIMPLE SEQUENCING!!

– Un paquete sin etiquetar correctamente es un paquete no valido, aunque se pueda guardar como un .zip. ¡¡SIEMPRE HAY QUE VALIDAR ANTES DE GUARDAR EL PAQUETE COMO UN .zip!!

3. EMPAQUETADO

– El empaquetado y etiquetado de un paquete debe realizarse siempre con el perfil Avanzado de Agrega Offline. El perfil Básico no permite rellenar todos los metadatos LOM-ES, y ofrece una vista limitada para generar paquetes SCORM 2004. ¡¡HAY QUE COMPROBAR SIEMPRE QUE EL PERFIL CONFIGURADO ES EL AVANZADO. EN CASO CONTRARIO SE DEBE CAMBIAR MEDIANTE LA OPCIÓN DE CONFIGURACIÓN DEL MENÚ PRINCIPAL DE AGREGA OFFLINE!!

3. EMPAQUETADO

– Todo paquete debe gestionar la trazabilidad de los contenidos , y ésta se implementa en los propios contenidos binarios de forma simultanea con la creación de los mismos.¡¡LA TRAZABILIDAD SON LLAMADAS A UNA API DE JAVASCRIPT ESTÁNDAR DEFINIDA EN SCORM 2004!! ¡¡AGREGA OFFLINE NO CUBRE NINGÚN ASPECTO DE LA TRAZABILIDAD: NO PUEDEN EDITARSE LOS CONTENIDOS PARA INTRODUCIR LAS LLAMADAS, NI GENERA LA API DE JAVASCRIPT NECESARIA. ÉSTA DEBE SER PROPORCIONADA JUNTO A LOS CONTENIDOS BINARIOS!!

3. EMPAQUETADO

– En todo paquete debe validarse la gestión de la trazabilidad tal como se explica en las transparencias siguientes.¡¡UN PAQUETE QUE NO GESTIONA SU TRAZABILIDAD, ES UN PAQUETE INCORRECTO!!

– En todo paquete debe validarse que los enlaces, botones o locuciones funcionan correctamente. ¡¡UN PAQUETE CON PROBLEMAS EN EL CONTENIDO, ES UN PAQUETE INCORRECTO!!

3. EMPAQUETADO

– El diseño de los contenidos binarios, los aspectos de secuenciamiento de los mismos, así como gran parte de los metadatos educativos se obtiene a partir de la ficha instruccional.¡¡PERO EXISTEN OTROS ASPECTOS DEL DISEÑO TALES COMO EL NOMBRE DE IDENTIFICADORES, ASPECTOS DE ACCESIBILIDAD, USABILIDAD, O DE ESTILO, METADATOS DE VALOR FIJADO POR RED.ES, ETC QUE SON PROPORCIONADOS POR RED.ES PARA CADA PROYECTO!!

3. EMPAQUETADO

– Al tratarse de contenidos multilingües, hay que asegurarse que en los paquetes correspondientes a un idioma determinado, no se mezclan locuciones o textos de otros idiomas.¡¡EN LOS PAQUETES QUE SE TRADUCEN NO SE PUEDE APROVECHAR AL 100% EL CONTENIDO GENERADO PARA OTRO IDIOMA, PUES LOS TEXTOS O LAS LOCUCIONES PUEDEN OCUPAR MÁS ESPACIO O TIEMPO EN IDIOMAS DIFERENTES.HAY QUE ADAPTARLOS!!

– La herramienta de empaquetado a usar es Agrega Offline.¡¡NO SE PUEDEN USAR OTRAS HERRAMIENTAS DE EMPAQUETADO COMO RELOAD, DADO QUE NO ESTÁN ADAPTADAS A LAS NECESIDADES DEL PROYECTO.POR LO QUE NO PODRÁN CARGARSE LOS OBJETOS DESARROLLADOS CON ESTAS HERRAMIENTAS EN AGREGA!!

3. EMPAQUETADO

– Todo paquete debe contener entre los archivos binarios que lo forma un archivo especial denominado Escenario.html. Este archivo debe permitir utilizar los contenidos del paquete fuera del contexto de un LMS, en el entorno de un navegador Web.¡¡EN LA GESTIÓN DE LA TRAZABILIDAD, SE DEBE TRATAR EL CASO DE QUE EL PAQUETE NO SE ENCUENTRE DENTRO DEL CONTEXTO DE UN LMS, PARA QUE EL USO DEL MISMO NO GENERE LLAMADAS DE ERROR, Y PUEDA NAVEGARSE POR EL MISMO!!

3. EMPAQUETADO

– El archivo Escenario.html es generado junto con los contenidos binarios. ¡¡AGREGA OFFLINE NO DA SOPORTE A LA CREACIÓN DEL ARCHIVO Escenario.html!!

– La ejecución via el archivo Escenario.html, hace que se pierdan algunas características que si dispone la versión que se ejecuta sobre un LMS como el Control de la trazabilidad o la secuenciación guiada en caso de existir.¡¡EN UN OA EL ARCHIVO Escenario.htmlCOINCIDE CON EL ARCHIVO PRINCIPAL DEL ÚNICO RECURSO DEL PAQUETE, HABIÉNDOLE ELIMINADO LAS POSIBLES LLAMADAS A LA API DE JAVASCRIPT, O BIEN HABIÉNDOSE TRATADO EN LAS PROPIAS FUNCIONES JAVASCRIPT.ENUNA SD, EL ARCHIVO Escenario.html, HAY QUE REALIZARLO AD HOC!!

3. EMPAQUETADO

– En una SD no pueden existir referencias cruzadas entre los paquetes y recursos que lo forman. Concretamente debe evitarse la doble navegación via los contenidos binarias o bien via SCORM 2004. ¡¡UN PAQUETE CON DOBLE NAVEGACIÓN ES UN OBJETO INVALIDO. LA DOBLE NAVEGACIÓN SÓLO PUEDE SER DETECTADA MANUALMENTE, AGREGA OFFLINE NO ES CAPAZA DE VALIDAR ESTE TIPO DE ASPECTOS!!

3. EMPAQUETADO

– Dado que en los contenidos se va a gestionar la trazabilidad de los mismos, todos los recursos que se creen a partir de los contenidos binarios, deben declararse como SCOs y no como ASSETs.

3. EMPAQUETADO

• La verificación de la corrección de los aspectos estructurales del paquete se realizará a través de la función de validación que presenta Agrega Offline.

• Los aspectos propios del contenido se verificarán manualmente mediante su navegación.

3. EMPAQUETADO

• Todo paquete debería tener en su interior:– Esquemas de LOM-ES y SCORM 2004

– Archivo imsmanifest.xml– Carpetas o archivos de los contenidos

binarios que conforman el paquete.– API JavaScript.

– Escenario.html

3. EMPAQUETADO

• Entre los contenidos que debe disponer un paquete, se encuentra la API de JavaScript. Esta API debe ser facilitada junto a los contenidos que se suben para crear el objeto.NO LA INSERTA DE MANERA AUTOMÁTICA AGREGA OFFLINE.

3. EMPAQUETADO

• Otro elemento que debe contener un paquete es un archivo Escenario.html. Se trata de un archivo que sirve para poder usar el paquete fuera del contexto de un LMS. Este archivo NO SE PUEDE GENERAR DESDE AGREGA OFFLINE, DEBE SER GENERADO POR EL PRODUCTOR DE LOS CONTENIDOS.

3. EMPAQUETADO

• Agrega es capaz de generar un archivo especial index.html, diferente del archivo Escenario.html anteriormente mencionado, el cual simula el previsualizador de Agrega fuera del contexto de Agrega.

3. EMPAQUETADO

4. CATALOGACIÓN• Elementos de partida.

– Paquete SCORM 2004– Ficha Instruccional.– Otros aspectos de diseño y estilo proporcionados

por Red.es– Agrega Offline

• Producto que se genera.Paquete SCORM 2004 etiquetado.

• Herramienta de catalogaciónAgrega Offline

• Ciclo de vida:

Recursos

Objetos Aprendizaje

Crear organización Etiquetado Empaquetado

Archivos

Parte del ciclo de vida

cubierto

4. CATALOGACIÓN

• Dentro de un paquete, existen diferentes lugares en los que se pueden introducir metadatos:– Nivel de objeto– Nivel de Organización.– Nivel de item.– Nivel de Recurso.

• En cualquiera de los casos, la forma de asociar los metadatos, es mediante la opción de “Catalogar”

4. CATALOGACIÓN

• Todo paquete SCORM 2004 debe estar catalogado con respecto al perfil de aplicación LOM-ES.¡¡SOLO SE CATALOGA A NIVEL DE PAQUETE!!

• Para catalogar el paquete se usará la funcionalidad de catalogación de Agrega Offline.¡¡SE DEBE USAR ESTRICTAMENTE AGREGA OFFLINE. CUALQUIER OTRA HERRAMIENTA DE CATALOGACIÓN COMO RELOAD, DARÁ LUGAR A PAQUETES INVALIDOS!!

4. CATALOGACIÓN

• Todo paquete catalogado debe validarse su catalogación a través de la función de validación de Agrega Offline.¡¡UN PAQUETE CON ERRORES DE CATALOGACIÓN PUEDE SER GUARDADO COMO UN ARCHIVO .ZIP, POR LO QUE LA POSIBILIDAD DE GUARDAR COMO UN .ZIP, NO ASEGURA QUE EL PAQUETE SEA CORRECTO!!

4. CATALOGACIÓN

• En los formularios que ofrece Agrega Offline para rellenar las categorías de metadatos de LOM-ES esnecesario rellenar:– Todos los campos obligatorios que indica LOM-ES.¡¡EN

AGREGA OFFLINE HAY UN INDICATIVO GRÁFICO CON * QUE INDICA ESTOS CAMPOS!!

– Aquellos campos que de manera explícita Red.es, haya indicado a través de la documentación que se entrega en cada Proyecto.

– Una instancia de la categoría 9, por cada taxonomía y tesauro indicados para estos proyectos: ETB, Árbol Curricular, Accesibilidad, Nivel Educativo, Competencias y Disciplina.¡¡EN AGREGA OFFLINE SE PUEDEN INCLUIR TANTAS INSTANCIAS DE LA CATEGORIA 9 COMO SISTEMAS DE CLASIFICACIÓN SE USEN PARA CATALOGAR!

4. CATALOGACIÓN

• Todos los campos con texto libre deben describirse en el idioma principal del paquete, y debe señalarse dicho idioma mediante el atributo del idioma que acompaña a estos campos.¡¡ESTE ES UN FALLO HABITUAL. ESCRIBIR EL VALOR DE TEXTO LIBRE Y NO INDICAR EL IDIOMA DE DICHO VALOR!!

• Los campos con vocabularios definidos, deben describirse en inglés. Si se usa Agrega Offline, estos campos se distinguen del resto al tratarse de campos con listas desplegables, y salvo manipulación, no debería poderse rellenar de otra forma que con el término del desplegable.

4. CATALOGACIÓN

• Existe una documentación explícita de cómo rellenar la categoría 9 con cada una de las taxonomías y tesauros, que puede encontrarse en la web del proyecto Agrega. www.proyectoagrega.es

• Salvo indicación explícita, solo se rellenan los metadatos a nivel de paquete, y nunca para otros elementos más internos tales como items, recursos,etc.

4. CATALOGACIÓN

• La verificación de la corrección de los aspectos sintácticos del etiquetado del paquete se realizará a través de la función de validación que presenta Agrega Offline en la zona de catalogación o de edición del paquete(en ambas zonas se validan los metadatos).

• La validación de los aspectos semánticos de la catalogación sólo se pueden verificar manualmente.

4. CATALOGACIÓN

5. TRAZABILIDAD• Elementos de partida.

– Contenidos binarios.– Ficha Instruccional.– Otros aspectos de diseño y estilo

proporcionados por Red.es

• Producto que se genera.Contenidos binarios con gestión de trazas.

• Herramienta de catalogaciónHerramienta de edición que se estéusando para crear los contenidos binarios.

CREACIÓN CONTENIDOS

BINARIOS

ADICIÓN DE TRAZAS A LOS CONTENIDOS

BINARIOS

La adición de las trazas a los contenidos binarios, se realiza en el momento de creación de dichos contenidos:

5. TRAZABILIDAD

COMO LOS CONTENIDOS TIENEN EL API JAVASCRIPT PERO TAMBIEN SE PUEDEN EJECUTAR FUERA DE UN LMS – ES NECESARIO QUE EL PRODUCTOR TRATE LOS ERRORES DE LA FUNCION CUANDO ESTE SIN PRESENCIA DE LMS

• La navegación en un paquete se describe y gestiona mediante el uso de JavaScript embebido en los binarios que forman el contenido de los paquetes.

• SCORM 2004 describe una API estándar de funciones JavaScript, que todo LMS compatible con este tipo de empaquetado debería tener implementado.

5. TRAZABILIDAD

• La lógica de proceso de estas funciones puede ser modificada, e incluso se pueden definir más funciones de las que propone el API, en base a las funciones que se sabe que están implementadas.

5. TRAZABILIDAD

• Un script mínimo debe proporcionar funciones para inicializar y terminar la sesión de comunicación automáticamente si existe una instancia de la API de SCORM 2004.Además debe poner el estado de terminación del SCO a “completado” cuando el SCO termina.

5. TRAZABILIDAD

• El script debe implementar al menos 4 funciones básicas:– ScanForAPI(win).Esta función busca la existencia

de una instancia de la API de SCORM 2004 en el sistema.

– GetAPI(win).Esta función recupera una instancia de la API de SCORM 2004, en caso de existir en el sistema.

– ScormInitialize(). Esta función inicializa la comunicación con una instancia de la API de SCORM 2004.

– ScormTerminate().Esta función finaliza la comunicación con una instancia de la API de SCORM 2004.

5. TRAZABILIDAD

• Un SCO puede reportar a un LMS dos tipos de informaciones:– Información de progreso, que puede ser a su vez de dos

tipos:• Estado de completitud .Toma el valor de completado o no

completado.• Medida del progreso. Es un ratio entre lo que está realizado y lo

que puede ser realizado, y se representa como un valor en coma flotante entre 0 (nada realizado) y 1 (completamente realizado).

– Información del éxito, que puede ser a su vez de dos tipos:

• Estado del éxito. Toma el valor de aprobado o fallado.• Medida del éxito.Es un valor escalado en el rango entre -1.0 y

1.0, donde 0 representa no éxito, 1.0 representa éxito total, y los valores negativos representan penalizaciones.

• Las posibles variables que pueden usarse para manejar este tipo de informaciones se encuentran en el anexo de estas transparencias.

5. TRAZABILIDAD

• Para el intercambio de datos es necesario implementar las siguientes funciones:– ScormGetLastError().Esta función recupera

un código que representa el estado de error de la sesión de comunicación después de la última llamada a la API.

– ScormGetErrorString(Estado de Error). Esta función recupera el mensaje de error asociado a un estado error determinado especificado en sErr.

5. TRAZABILIDAD

– ScormGetValue(Elemento de datos). Esta función permite recuperar datos almacenados en el entorno de ejecución, hace uso de las funciones ScormGetLastError para detectar si se ha producido algún error, y de ScormErrorStringpara mostrar mensajes de error en caso de haberse producido alguno. Para ello toma como parámetros el elemento de datos del modelo CMI que se quiere consultar.

– ScormSetValue(Elemento de datos,Valor).Esta función permite enviar datos para su almacenamiento en el entorno de ejecución. Para ello toma como parámetros el elemento de datos del modelo CMI que se quiere actualizar, y el valor con el que se quiere actualizar(se trata de valores predefinidos para cada elemento de datos).

5. TRAZABILIDAD

• SCORM 2004 permite a un SCO crear hasta 250 registros de interacción. Cada registro contiene un identificador para esa interacción.

• Durante una sesión de comunicación, el entorno de ejecución almacena los registros en un array indexado. El array de interacciones solo persiste durante la sesión de comunicación y el entorno de ejecución puede usar distintas aproximaciones para almacenar estos registros entre sesiones.

• La colección de registros de interacción no se encuentra almacenado en ningún orden determinado. Debido a esto último, en una comunicación posterior, los registros de interacción podrían aparecer en un orden diferente. En este sentido si se van a usar de una sesión previa, habría que encontrar que índice del array se le asignó en la nueva sesión, para lo cual se buscará los registros por el identificador de interacción.

5. TRAZABILIDAD

• Para gestionar esto se añaden nuevas funciones al script de SCORM:– ScormInteractionAddRecord toma como parámetro el

identificador de una interacción y un tipo de interacción válida. Retorna un entero que corresponde al índice del array de registros o -1 si ocurre algún error. Si un registro de interacción con el mismo identificador y el mismo tipo ya existe, la function no hace nada y retorna el índice del registro existente. Si un registro de interacción con el mismo identificador pero con diferente tipo ya existe, la function falla. Si el número de registros de interacción permitidos se excediera por la adicción de un nuevo registro, la función fallaría.

– ScormInteractionGetCount no toma ningún parámetro y retorna un valor entero que representa el número de registros de interacción existentes.

5. TRAZABILIDAD

– ScormInteractionGetData toma como parámetro el identificador de la interacción y el elemento del modelo de datos dentro del registro de la interacción, y retorna un valor. Si el valor es una cadena vacía, podría indicar un posible error. La cadena que identifica el elemento de datos es la que aparece a la derecha de “interactions.n..” en la documentación de SCORM para el modelo de datos.

– ScormInteractionGetIndex toma como parámetro el identificador de la interacción. Retorna un entero, que es el índice del registro de la interacción o -1 si el registro no existe. Se puede usar esta función para chequear si existe un registro para esa interacción.

5. TRAZABILIDAD

– ScormInteractionSetData toma como parámetro el identificador de una interacción, el elemento del modelo de datos dentro del registro de interacción y el valor a poner. Retorna cierto o falso. Si retorna falso, se puede analizar el estado de error. Dado que los datos no pueden ser almacenados en un registro de interacción hasta que el identificador es almacenado en el registro, y algunos datos no pueden ser almacenados apropiadamente a menos que el tipo de interacción sea conocida, la función fallará si el registro de interacción no ha sido creado previamente por una llamada ScormInteractionAddRecord. La cadena que identifica el elemento de datos es la que aparece a la derecha de “interactions.n..” en la documentación de SCORM para el modelo de datos.

5. TRAZABILIDAD

• La forma más fácil de convertir un asseten un SCO es embeberlo dentro de una página HTML. Para otros assets, se crea una página que contenga un lugar para cargar el asset. Muchos assets, tales como archivos pdf, imágenes,o archivos de texto pueden ser lanzados directamente por un browser. Sin embargo para usarlos como SCO se requieren scripts.

5. TRAZABILIDAD

• Un SCO genérico puede ser usado como envoltorio para cualquier asset que pueda generarse como un frameset. El script del frameset gestiona su comportamiento como un SCO, y el frame “stage” es usado para mostrar el asset pasivo. El único aspecto particularizable del envoltorio es la URL relativa del asset pasivo, la cual debe ser proporcionada como fuente para el frame “stage”.

5. TRAZABILIDAD

• Si se usa Flash para crear un SCO, la película Flash debe ser mostrada en un objeto Flash embebido en una página web. La página web en si misma es el SCO, y el elemento resource que describe el SCO en el manifest del paquete SCORM especifica la URL de la página HTML.

5. TRAZABILIDAD

• Es recomendado usar JavaScript en la página HTML que maneja la gestión de las sesiones de comunicación.

• Es recomendable que todas las comunicaciones entre ActionScript y la implementación de la API sean realizadas a través de funciones JavaScript descansando en la página HTML. Es importante enviar los datos si algo significante está ocurriendo, en vez de esperar a que finalice la película.

5. TRAZABILIDAD

• Hay dos formas de verificar que se ha gestionado correctamente la trazabilidad:– Cargar el paquete en el RunTime que ofrece

ADL para SCORM 2004:

http://www.adlnet.gov/downloads/downloadPage.aspx?id=280

– Cargar el paquete en el RunTime online gratuito que ofrece Rustici:

http://www.scorm.com/

5. TRAZABILIDAD

6. ENTREGA DE LOS PAQUETES

• Los paquetes de contenidos deben entregarse en formato zip. Nunca descomprimidos.

• La estructura de carpetas más adecuada para realizar la entrega es una carpeta por idioma, y dentro de esa carpeta, una subcarpeta por cada SD que contenga los archivos .zip de la SD y de todos los OAsque conforman la SD.

• Red.es distribuye un documento denominado Hoja_de_entrega, en la que aparecen unos requisitos mínimos de calidad que deberían tenerse en cuenta en la realización de un paquete. Estos requisitos son complementarios a todos los aspectos técnicos y estructurales que se han comentado aquí, y que aparecen en las fichas instruccionales.


• Estos requisitos se refieren preferentemente a aspectos estéticos, de estilo, usabilidad, accesibilidad, y algunos técnicos.

• No puede realizarse una entrega sin haberse comprobado y rellenado esta ficha de calidad.


7. CONTACTOS/DUDAS

• Foro de preguntas técnicas: http://es.groups.yahoo.com/group/proyectoagrega/

• Dirección de email para dudas muy concretas (mejor utilizar el foro):[email protected]

ANEXOS

Ejemplo Empaquetado OAEjemplo Empaquetado SD

Ejemplo CatalogaciónModelo de Datos Runtime

EJEMPLO EMPAQUETADO OA

• Se va a desarrollar un ejemplo de creación de un OA denominado “El tamaño lineal de los objetos” formado por los archivos que se ven en la captura.


• Para crear el OA se usa la opción “Crear ODE”


• Se rellena el título del ODE que se va a crear


• Se sube al área de Archivos los contenidos del OA. Para ello primero se zippean.


• A continuación se sube los contenidos zippeados.


• Se crea un recurso con el contenido subido:


• Se crea la organización con el item en la zona de Organizations.


• A continuación se cataloga el objeto seleccionando la opción de “Catalogar”desde la organización principal


• Visualización final:

EJEMPLO EMPAQUETADO SD

• Se va a desarrollar una SD formado por los siguientes elementos de información:– El tamaño lineal de los objetos.– Medición con unidades no convencionales.– Instrumentos de medición y unidades convencionales.– El metro: sus múltiplos y divisores. equivalencias entre

unidades.– Forma simple y compleja de expresión de longitudes.– Problemas y curiosidades.– Ayuda. – Guía del profesor.– Glosario.


• En el momento de elegir qué elementos se implementarán como recursos y cuales como submanifiestos, influye una serie de factores, que principalmente se basan en:– Futura reutilización del contenido.– Entidad propia desde el punto de vista

pedagógico y del conocimiento.


• En este caso concreto tienen entidad propia, y merece la pena poder reutilizar el contenido en el caso de los elementos:– El tamaño lineal de los objetos.– Medición con unidades no convencionales.– Instrumentos de medición y unidades

convencionales.– El metro: sus múltiplos y divisores. equivalencias

entre unidades.– Forma simple y compleja de expresión de longitudes.– Problemas y curiosidades.


• Para estos elementos surge la cuestión de si deben ir empaquetados en forma de recursos o en forma de submanifiestos.

• Desde el punto de vista de Scorm, ambas formas de implementación serían correctas.


–De los elementos que se han listado anteriormente se van a considerar como submanifiestos todos, salvo los elementos: Guía del Profesor, Ayuda y Glosario.

–Para ello hay que hacer dos tratamientos diferentes:•Aquellos elementos que van a ir empaquetados en forma de recursos, se deben subir como archivos, y convertirse en recursos.

•Aquellos elementos que van a ir empaquetados en forma de submanifiestos, se deben crear paquetes Scorm 2004 de estos elementos, y agregarse al objeto principal que se está realizando.

–A continuación crear la estructura del organization con los items correspondientes y referenciar los elementos que son recursos y los elementos que son submanifiestos.


• Se crean los paquetes Scorm a partir de los contenidos de cada elemento.


• Creación de la estructura de la organización vacía:


• Se suben los contenidos binarios en forma de archivos que se van a convertir en recursos


• Se crean los recursos a partir de los binarios que se han subido como archivos:


• Se agregan los submanifiestos que se han creado previamente, y que serán referenciados desde la organización:


• Se referencian los recursos y los submanifiestos creados desde los items de la organización creada.


• Visualización final:

EJEMPLO CATALOGACIÓN

MODELO DE DATOS DEL RUN-TIME

• Significado de las principales variables que usa la API de JavaScript:– cmi.comments_from_learner: texto para el

usuario.

– cmi.comments_from_lms: comentarios y anotaciones que se ofrecen al usuario

– cmi.completionThreshold: indica cuánto ha progresado el usuario hacia la finalización del SCO


– cmi.credit: indica si se calificará el rendimiento del usuario en este SCO.

– cmi.entry: indica si el usuario ha accedido previamente al SCO

– cmi.exit: indica cómo y por qué el usuario ha dejado el SCO.

– cmi.interactions: define información relativa a una interacción para medida o verificación.

– cmi.launch_data: datos específicos del SCO que éste puede usar para su iniciación.

– cmi.learner_ide: identifica al usuario para el que se ha lanzado la instancia del SCO.


– cmi.learner_name: nombre del usuario– cmi.learner_preference: preferencias del

usuario asociadas al uso del SCO.– cmi.location: localización dentro del sco– cmi.max_time_allowed:tiempo máximo para

ejecutar un intento del SCO.– cmi.mode:modos en los que puede

presentarse el SCO al usuario.– cmi.objectives:objetivos de aprendizaje o

rendimiento asociados al SCO


– cmi.progress_measure: medida del progreso que el estudiante ha hecho hacia la terminación del SCO

– cmi.scale_passing_score: puntuación escalada para un SCO

– cmi.score: puntuación del usuario para el SCO– cmi.session_time: tiempo que ha pasado el

usuario en la sesión actual del SCO– cmi.success_status:indica si el usuario ha

superado el SCO– cmi.suspend_data: ofrece información creada por

un SCO como resultado de interacción con un usuario


– cmi.time_limit_action: indica qué debería hacer el SCO si se excede el tiempo máximo permitido.

– cmi.total_time: tiempo acumulado de todos los intentos del usuario anteriores a la sesión actual.

DOCUMENTACIÓN

• Se recomienda consultar como documentación complementaria, aquella que se encuentra en la zona de documentación del sitio del proyecto, www.proyectoagrega.es:

pautas recomendadas producción

Technology