Pautas De Produccion

PAUTAS DE PRODUCCIÓN

ÍNDICE 1. 2. 3. 4. 5. 6. 7.

REQUISITOS PREVIOS PROYECTOS RED.ES EMPAQUETADO CATALOGACIÓN TRAZABILIDAD ENTREGA 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.a spx?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: Idioma Inglés

Idioma Castellano Generación  OAS

Generación  SD

….

Generación  OAS

Generación  SD

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

3. EMPAQUETADO • Ciclo de vida: Archivos

Recursos Crear  organización Objetos  Aprendizaje

Etiquetado

Empaquetado

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_Ref erencia_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 El ciclo de vida del empaquetado de un OA es: UPLOAD  CONTENIDOS  BINARIOS

CREACIÓN RECURSO

CREACIÓN  ORGANIZATION  

INSERTAR  SECUENCIACIÓN GUIADA

INSERTAR  METADATOS

ASOCIAR  RECURSO A ITEM

VALIDAR ,  PREVISUALIZAR Y  GUARDAR .ZIP

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 El proceso de creación de una SD consta  de 2 fases: CREACIÓN  PAQUETES CONTENIDO 

CREACIÓN  PAQUETE CONTENEDOR

3. EMPAQUETADO El ciclo de vida del empaquetado de una SD es:

UPLOAD CONTENIDOS BINARIOS  Y SUBMANIFIESTOS

INSERTAR SECUENCIACIÓN GUIADA

VALIDAR , PREVISUALIZAR Y  GUARDAR .ZIP

CREACIÓN RECURSOS

INSERTAR METADATOS

CREACIÓN ORGANIZATION  

ASOCIAR RECURSOS  Y  SUBMANIFIESTOS A ITEMS

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.html COINCIDE  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.EN UNA 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.

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ón Agrega Offline

4. CATALOGACIÓN • Ciclo de vida: Archivos

Parte del ciclo  de vida  cubierto

Recursos Crear  organización Objetos  Aprendizaje

Etiquetado

Empaquetado

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 es necesario  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.

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ón Herramienta de edición que  se esté usando  para crear los contenidos binarios.

5. TRAZABILIDAD La adición de las trazas a los contenidos  binarios, se realiza en el momento de  creación de dichos contenidos: CREACIÓN  CONTENIDOS BINARIOS

ADICIÓN DE TRAZAS  A LOS CONTENIDOS  BINARIOS

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

5. TRAZABILIDAD • 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 ScormErrorString para 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 asset en 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/downloadPag e.aspx?id=280 – Cargar el paquete en el RunTime online gratuito  que ofrece Rustici: http://www.scorm.com/

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 OAs que conforman la SD.

6. ENTREGA DE LOS PAQUETES • 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.

6. ENTREGA DE LOS PAQUETES • 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 OA Ejemplo Empaquetado SD Ejemplo Catalogación Modelo 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.

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

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

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

EJEMPLO EMPAQUETADO OA • A continuación se sube los contenidos  zippeados.

EJEMPLO EMPAQUETADO OA

EJEMPLO EMPAQUETADO OA

EJEMPLO EMPAQUETADO OA • Se crea un recurso con el contenido subido: 

EJEMPLO EMPAQUETADO OA

EJEMPLO EMPAQUETADO OA

EJEMPLO EMPAQUETADO OA

EJEMPLO EMPAQUETADO OA

EJEMPLO EMPAQUETADO OA

EJEMPLO EMPAQUETADO OA

EJEMPLO EMPAQUETADO OA

EJEMPLO EMPAQUETADO OA

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

EJEMPLO EMPAQUETADO OA

EJEMPLO EMPAQUETADO OA

EJEMPLO EMPAQUETADO OA

EJEMPLO EMPAQUETADO OA

EJEMPLO EMPAQUETADO OA

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

EJEMPLO EMPAQUETADO OA

EJEMPLO EMPAQUETADO OA

EJEMPLO EMPAQUETADO OA • 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.

EJEMPLO EMPAQUETADO SD • 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.

EJEMPLO EMPAQUETADO SD • 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. – – – –

EJEMPLO EMPAQUETADO SD • 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.

EJEMPLO EMPAQUETADO SD – 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.

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

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

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

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

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

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

EJEMPLO EMPAQUETADO SD • Visualización final:

EJEMPLO CATALOGACIÓN

EJEMPLO CATALOGACIÓN

EJEMPLO CATALOGACIÓN

EJEMPLO CATALOGACIÓN

EJEMPLO CATALOGACIÓN

EJEMPLO CATALOGACIÓN

EJEMPLO CATALOGACIÓN

EJEMPLO CATALOGACIÓN

EJEMPLO CATALOGACIÓN

EJEMPLO CATALOGACIÓN

EJEMPLO CATALOGACIÓN

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

MODELO DE DATOS DEL RUN‐TIME – 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.

MODELO DE DATOS DEL RUN‐TIME – 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

MODELO DE DATOS DEL RUN‐TIME – 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

MODELO DE DATOS DEL RUN‐TIME – 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: