SCO (Sharable Content Object)

O que é um SCO (Sharable Content Object)?

Um SCO — Sharable Content Object, ou objeto de conteúdo partilhável — é a mais pequena unidade de conteúdo que um LMS consegue lançar e da qual consegue registar resultados dentro da norma SCORM. Dito de forma curta: quando a sua plataforma regista que um colaborador concluiu algo, aquilo que concluiu foi um SCO.

É um conceito técnico com consequências muito práticas para quem gere formação. A forma como se dividem os SCO de um curso decide o que o seu LMS consegue medir: se todo o curso for um único SCO, só saberá se foi terminado ou não; se estiver repartido em seis, saberá exatamente em qual as pessoas encalham. Essa decisão toma-se ao publicar o curso e depois é cara de desfazer.

SCO face a asset: a diferença que decide tudo

O SCORM classifica tudo o que vai dentro de um pacote em dois tipos de recurso: assets e SCOs. E a fronteira entre ambos resume-se a uma só coisa.

Um asset é conteúdo estático que se mostra ao aluno: uma imagem, um PDF, um vídeo, uma folha de estilos. Apresenta-se e pronto. Um SCO também é feito de um ou vários ficheiros, mas tem de conseguir comunicar com o LMS através da Runtime API. Essa capacidade de falar com a plataforma é a única coisa que transforma um recurso em SCO.

A consequência é muito concreta: se empacotar um PDF como asset, o seu LMS poderá mostrá-lo, mas não saberá se alguém o abriu. Para que fique registo, essa peça tem de ser um SCO.

O que um SCO tem de fazer para ser um SCO

A especificação impõe três obrigações a qualquer SCO. Se alguma falhar, o conteúdo vê-se na mesma mas o acompanhamento não funciona:

1. Encontrar a API do LMS. O SCO procura um objeto JavaScript na janela que o contém. Chama-se API no SCORM 1.2 e API_1484_11 no SCORM 2004. Se não o localizar, não há acompanhamento possível.
2. Abrir a sessão antes de qualquer outra coisa. Todo o SCO deve chamar Initialize — LMSInitialize no 1.2 — antes de enviar ou pedir um único dado.
3. Fechá-la sempre. Deve chamar Terminate — LMSFinish no 1.2 — em todos os caminhos de saída, incluindo o de fechar o separador sem avisar.

E há uma regra de sentido que explica boa parte dos problemas de rastreio: a conversa é sempre iniciada pelo SCO. O LMS responde quando lhe perguntam, mas nunca pergunta ele. Se o SCO se cala, a plataforma não tem forma de descobrir o que aconteceu: simplesmente não regista nada.

Um só SCO ou vários: como decidir a granularidade

Esta é a decisão prática mais importante em torno do conceito, e quase ninguém a toma conscientemente: herda-se daquilo que a ferramenta de autoria faça por omissão. Convém decidi-la, porque cada SCO tem o seu próprio registo no LMS e isso define o nível de detalhe de todos os relatórios que verá depois.

A regra de ouro é a mesma que rege qualquer objeto de aprendizagem: um SCO deveria cobrir um único objetivo de aprendizagem, ser suficientemente pequeno para poder ser reutilizado noutro curso e suficientemente grande para ensinar algo por si só. Entre esses dois extremos, escolha consoante o que precisa de medir:

O que guarda cada SCO e onde está o limite

Cada SCO tem o seu próprio conjunto de dados no LMS, separado do dos restantes: estado de conclusão, pontuação, tempo de sessão, marcador de posição e um campo livre, cmi.suspend_data, onde o curso guarda o seu estado interno para poder ser retomado.

Daí decorrem duas coisas que surpreendem muita gente à primeira:

Os SCO não falam entre si. Não existe um canal direto entre eles. Se o módulo 3 precisasse de saber o que o aluno respondeu no módulo 1, a norma não o contempla: quem decide a ordem e as condições de passagem é a sequenciação declarada no ficheiro imsmanifest.xml, não o conteúdo.

O campo de retoma tem um limite. Segundo a referência da especificação, cmi.suspend_data admite 4096 caracteres no SCORM 1.2 e 64 000 no SCORM 2004 (3.ª e 4.ª edição). É a causa mais comum de um curso longo “perder” o ponto onde o aluno ficou: o conteúdo tenta guardar mais estado do que cabe, e o que sobra é descartado sem aviso.

O que o SCO implica para os responsáveis de formação

Não é preciso escrever uma linha de código para que isto afete o seu trabalho. Estas são as decisões em que aparece:

• Defina o que vai poder medir antes de encomendar o curso. Se precisa de saber em que módulo as pessoas abandonam, peça explicitamente um pacote com um SCO por módulo. Pedi-lo depois implica voltar a publicar e, em muitos LMS, perder o histórico de quem já o tinha começado.
• Pergunte pela versão. O SCORM 1.2 é universalmente compatível mas mais limitado; o SCORM 2004 permite sequenciação entre SCO e um modelo de dados mais rico. Escolha consoante o que a sua plataforma admita, não consoante o mais recente.
• Verifique a compatibilidade do LMS. O acompanhamento só funciona se a plataforma expuser corretamente o adaptador da API. Um LMS compatível com SCORM garante que o SCO encontrará com quem falar.
• Desconfie dos cursos sem estado. Se um conteúdo aparece sempre como “não iniciado” apesar de as pessoas o abrirem, o mais provável é que tenha sido publicado como asset e não como SCO, ou que não esteja a fechar a sessão.

A EMASESA, a empresa municipal de águas de Sevilha, utilizou o isEazy Author para criar os seus cursos SCORM em tempo recorde e publicá-los diretamente no seu LMS, com acompanhamento rigoroso do progresso por parte da equipa de RH.
Descubra como a EMASESA criou os seus cursos e-learning →

Limitações do modelo SCO

O SCO resolveu muito bem o problema para o qual foi concebido — conteúdo portável entre plataformas —, mas tem fronteiras claras:

• Dados isolados. Cada SCO guarda o seu e não partilha nada com os restantes, o que complica qualquer percurso que dependa de decisões tomadas num módulo anterior.
• Só dentro do LMS e do navegador. O SCO precisa de um reprodutor SCORM que exponha a API. Fora daí — uma aplicação nativa, uma sessão presencial, uma ferramenta de terceiros — não há registo.
• A granularidade congela ao publicar. Passar de um SCO para seis não é editar o curso: é voltar a empacotá-lo e a carregá-lo.
• Não mede o que acontece fora do curso. Para isso existe o xAPI, que regista experiências de aprendizagem sem depender de uma janela de navegador aberta contra um LMS.

O SCO na prática: o que a ferramenta de autoria resolve

No dia a dia, quem concebe a formação não constrói SCOs à mão: gera-os a ferramenta de autoria ao publicar. O que decide é a configuração, e é aí que convém saber o que se está a escolher.

O isEazy Author publica em SCORM 1.2 e SCORM 2004 gerando o pacote completo — manifesto, recursos e as chamadas de início, gravação e fecho de sessão — sem configuração técnica adicional. Isso evita as duas falhas que mais se repetem: cursos que ficam em “incompleto” porque nunca fecham a sessão, e cursos que não retomam onde o aluno ficou porque transbordam o campo de estado.