Substituir os Open Badges nativos do Moodle pelo Badges Ninja (Melhor Designer, Mesma API)

O Moodle já vem com Open Badges nativos, mas o designer é limitado e a experiência do destinatário fica fechada dentro do Moodle. Emite credenciais Badges Ninja a partir das conclusões do Moodle em vez disso.

Nacho Coll Por Atualizado 8 min de leitura
O Moodle já vem com Open Badges nativos, mas o designer é limitado e a experiência do destinatário fica fechada dentro do Moodle. Emite credenciais Badges Ninja a partir das conclusões do Moodle em vez disso.

O Moodle emite Open Badges nativamente desde a versão 2.5, e para muitos administradores de curso isso já é motivo suficiente para nunca procurarem outra opção. Vem incorporado, é gratuito e tecnicamente produz uma credencial conforme os padrões. Então porque é que tantos administradores do Moodle acabam frustrados quando chegam ao quinquagésimo emblema?

A resposta honesta: o sistema de emblemas do Moodle foi concebido para cumprir um requisito de conformidade, não para ser um produto de credenciamento. Funciona, mas funciona da forma como funciona uma funcionalidade acrescentada a um LMS — funcional, datada e limitada pelas restrições da plataforma em que vive. Se já tentaste fazer um emblema do Moodle parecer algo diferente de um ícone circular de clip-art, ou já viste um formando a perguntar “espera, onde é que eu vejo mesmo isto?”, já conheces esta lacuna.

Isto não é uma crítica ao Moodle — é um LMS excelente e o seu motor de critérios de emblemas (conclusão de curso, conclusão de atividade, atribuição manual, pertença a coorte) está genuinamente bem pensado para despoletar uma credencial. O problema é tudo o que acontece depois do desencadeador: as ferramentas de design, a experiência do destinatário e a visibilidade do emblema fora da tua instância do Moodle. É exatamente para isso que o badges.ninja foi construído, e não tens de abdicar da lógica de conclusão do Moodle para o utilizar — apenas apontas o desencadeador para um motor de emissão diferente.

Onde os emblemas nativos do Moodle ficam aquém

O designer é um compositor de imagens baseado em coordenadas, não uma ferramenta de design. O editor de emblemas do Moodle permite escolher uma imagem de base, acrescentar algumas sobreposições de ícones pré-definidos e ajustar a posição com deslocamentos em píxeis. Não há biblioteca de formas, não há sistema de paletas, não há opções de tipo de letra além do que já vem incorporado no conjunto de ícones. Se a tua organização tem uma marca — um logótipo, uma paleta de cores, uma linguagem visual própria para as tuas certificações — o editor do Moodle não consegue exprimir isso. A maioria das instituições acaba por desenhar a arte do emblema no Photoshop ou no Canva e a carregar um PNG plano, o que anula o propósito de ter um designer incorporado.

Os destinatários precisam de sessão iniciada no Moodle para verem os seus próprios emblemas. Os emblemas atribuídos a um estudante ficam dentro da página de perfil dele no Moodle. Se já terminou o curso, esqueceu as credenciais institucionais, ou a instituição entretanto desativou a conta dele, o emblema desaparece efetivamente do lado dele — ainda que a asserção subjacente possa continuar a ser resolvida pelo conector de backpack do Moodle ou pela página pública do emblema. Não existe um local dedicado, com marca própria e sempre acessível onde um destinatário possa iniciar sessão apenas com o email e ver todas as credenciais que alguma vez obteve em todos os cursos.

Partilhar é um pensamento tardio. O Moodle consegue enviar emblemas para um serviço compatível com o Mozilla Backpack, e expõe um URL de verificação público para cada emblema, mas não existe um fluxo integrado de “Adicionar ao LinkedIn”, nem um botão de partilha com um clique, nem análise de envolvimento sobre se alguém alguma vez viu o emblema depois de emitido. Para programas que querem que o emblema funcione como marketing boca a boca — bootcamps, entidades de formação contínua, formação empresarial — isso é um custo de oportunidade real.

As operações em massa são pouco práticas. Atribuir um emblema a uma coorte inteira funciona se todos concluírem a atividade que despoleta o emblema dentro do Moodle ao mesmo tempo. Mas se precisares de emitir retroativamente emblemas para uma coorte passada, importar conclusões históricas a partir de uma folha de cálculo, ou emitir um emblema por algo que aconteceu totalmente fora do LMS, acabas a escrever SQL diretamente na base de dados do Moodle ou a lutar com ferramentas de importação de CSV que não foram concebidas especificamente para emblemas.

O padrão de substituição: mantém os desencadeadores do Moodle, muda o emissor

Não precisas de migrar para fora do Moodle para resolver isto. O padrão mais limpo é deixar o Moodle continuar a fazer aquilo que faz bem — controlar a conclusão de cursos, a conclusão de atividades, a pertença a coortes — e fazer com que chame a API do Badges Ninja no momento em que uma condição de conclusão é despoletada, em vez de (ou juntamente com) atribuir o seu emblema nativo.

O Moodle suporta isto de várias formas:

  1. Webhook de conclusão de curso / polling do Moodle Web Services (REST). A API core_completion do Moodle expõe o estado de conclusão por utilizador e por curso. Uma tarefa agendada leve (uma tarefa cron agendada do Moodle, ou um job cron externo que consulta a API REST do Moodle) pode fazer polling à procura de inscrições recentemente concluídas e, para cada uma, chamar o endpoint de atribuição do Badges Ninja.

  2. Um hook de plugin local. Se tiveres um programador na equipa, o sistema de eventos do Moodle (\core\event\course_completed) pode ser observado por um pequeno plugin local que despoleta um pedido HTTP no instante em que a conclusão acontece — sem atraso de polling.

  3. Zapier/Make/n8n como cola, se preferires evitar mexer no código do Moodle — o Moodle pode enviar eventos de conclusão para um recetor de webhook que uma ferramenta de automação sem código transforma numa chamada de atribuição.

Aqui está a chamada real de atribuição, depois de teres o nome e o email de um utilizador que concluiu o curso:

curl -X POST https://api.badges.ninja/awards \
  -H "X-Api-Key: bws_3f9a1c2d4e5b6a7c8d9e0f1a2b3c4d5e" \
  -H "Content-Type: application/json" \
  -d '{
    "badgeId": "badge_moodle_course_completion",
    "recipient": { "name": "Jordan Alvarez", "email": "learner@example.edu" },
    "issuedOn": "2026-08-31"
  }'

Ou em Node, dentro de qualquer tarefa agendada ou recetor de webhook que estejas a correr:

const response = await fetch("https://api.badges.ninja/awards", {
  method: "POST",
  headers: {
    "X-Api-Key": process.env.BADGES_NINJA_API_KEY,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    badgeId: "badge_moodle_course_completion",
    recipient: { name: completedUser.fullname, email: completedUser.email },
    issuedOn: Date.now(),
  }),
});
const award = await response.json();

O email do destinatário é sujeito a hash SHA-256 em repouso, a atribuição recebe automaticamente um URL de verificação único, um código QR e um certificado em PDF A4, e — de forma crucial — o destinatário pode reclamá-la através de um início de sessão com link mágico em badges.ninja/me, sem necessitar de uma conta separada no Moodle. Consulta o formato completo do pedido/resposta na referência da API de awards e no guia de autenticação para perceberes como as chaves de API funcionam de ponta a ponta.

Se preferires fazer isto em lote — por exemplo, a preencher retroativamente as conclusões de um semestre inteiro de uma só vez, em vez de configurar eventos em tempo real — exporta as conclusões do Moodle como CSV e usa o fluxo de atribuição em massa diretamente, que suporta pausa/retoma para ficheiros grandes. Isto está coberto em detalhe em como emitir Open Badges a partir de um CSV.

A desenhar o próprio emblema

Depois de a canalização estar montada, o design do emblema em si demora minutos, não um pedido à tua equipa web. O designer visual dá-te mais de 80 modelos de formas, um sistema real de paleta de cores, bibliotecas de ícones e carregamento de tipos de letra personalizados — para que um emblema de “Estatística Avançada — Concluído” possa realmente parecer pertencer à marca da tua instituição, em vez de um ícone genérico de conquista do Moodle.

API Keys — empty state

Cada chave de API tem um âmbito definido e é revogável a partir do mesmo painel onde geres emblemas e emissores, pelo que entregar a credencial de integração a um programador (ou a uma ferramenta de automação como o Zapier) não significa partilhar o início de sessão da tua conta principal.

Create key — name form

Lado a lado: experiência do destinatário

Emblema nativo do MoodleBadges Ninja
Onde os destinatários o veemDentro do perfil do Moodle, exige sessão iniciadabadges.ninja/me, link mágico, sem palavra-passe
Verificação públicaSim, URL público por emblemaSim, endpoint JSON-LD do Open Badge v2.0
Ferramentas de designÍcone fixo + deslocamentos de posição80+ modelos, paletas, tipos de letra/ícones personalizados
Partilha no LinkedInManual, sem botão integradoFluxo nativo de Adicionar ao Perfil do LinkedIn
Emissão histórica em massaSQL ou solução manual via CSVAtribuição em massa integrada com pausa/retoma
Visibilidade de envolvimentoNenhumaEstatísticas de visualizações/partilhas por atribuição
Acesso após sair da instituiçãoLigado ao estado da conta do MoodlePersistente, propriedade do destinatário

O Moodle continua a ganhar numa coisa: se o único requisito for “o emblema existe, é tecnicamente conforme o Open Badge v2.0 e vive dentro do LMS que o estudante já utiliza”, os emblemas nativos não custam nada extra e não exigem trabalho de integração. A desvantagem surge a partir do momento em que te importas com a qualidade do design, a portabilidade depois de o curso terminar, ou transformar a emissão num sinal de recrutamento/marketing — o que acaba por ser a maioria das instituições.

Para uma visão mais alargada de como outras plataformas de Open Badges se comparam em preço e funcionalidades, consulta a comparação da plataforma de Open Badges mais barata. E se a tua instituição estiver a ponderar o Open Badge v2.0 face à especificação mais recente de credenciais verificáveis, Open Badge v2 vs v3 explicado aborda qual delas vale realmente a pena lançar hoje.

Pronto para emitir a tua primeira credencial verificável? Começa grátis no badges.ninja — designer visual, página de verificação pública, certificado em PDF, saída em Open Badge v2.0. Não é necessário cartão de crédito.

Nacho Coll

Sobre o autor

Founder & Engineer at Badges Ninja

Nacho founded Badges Ninja to make issuing verifiable digital credentials as simple as a single API call — Open Badge v2.0 badges and certificates, minted, hosted, and verifiable without standing up your own issuer infrastructure. Writes about the Open Badges spec, credential verification, and running a credentialing platform serverless on AWS, from the operator side of the wire.

Voltar ao Blog

Artigos Relacionados