Avaliação do Sistema de Conteúdo — Você na Facul

[FernandoAlmeidaPinto]

Prioridade: Baixa
Escopo: Análise end-to-end do fluxo de conteúdo educacional, da criação à entrega ao aluno
Serviços analisados: ms-simulado, api-vcnafacul, client-vcnafacul

---

1. Visão geral do que existe hoje

O sistema de conteúdo educacional da plataforma é composto por dois grandes blocos que, de forma bastante deliberada, já foram unificados dentro do ms-simulado: o banco de questões e os materiais de estudo (conteúdos). Essa decisão arquitetural — migrar o conteúdo da api-vcnafacul para o microserviço de simulado — é o passo mais importante já dado nessa direção, pois coloca questões e conteúdos no mesmo contexto de dados, abrindo caminho para a integração que ainda precisa ser construída.

1.1 Organização hierárquica

O conteúdo é organizado seguindo exatamente a mesma hierarquia das questões:

Matéria  (ex.: Matemática, Biologia)
  └── Frente  (ex.: Funções, Genética)
        └── Subject/Tema  (ex.: Funções Quadráticas, Lei de Mendel)
              └── Content  (o material de estudo em si)
                    └── FileContent  (o arquivo .docx armazenado no Blob)

Essa estrutura é intencional e correta: permite que questão e conteúdo habitem o mesmo universo de classificação, o que é o pré-requisito para qualquer integração futura entre as duas entidades.

1.2 O fluxo de produção de conteúdo (pipeline editorial)

O conteúdo percorre um ciclo de vida bem definido, com papéis separados:

Etapa 1 — Criação da demanda
Um gestor (gerenciadorDemanda) cria a "casca" do conteúdo: define título, descrição, e posiciona na hierarquia (Matéria > Frente > Subject). O conteúdo nasce com status Pending_Upload — existe no sistema, mas ainda não tem arquivo.

Etapa 2 — Upload do arquivo
Um colaborador com permissão uploadDemanda recebe a demanda e faz o upload de um arquivo .docx. O arquivo é enviado ao api-vcnafacul, que o armazena no Azure Blob Storage numa estrutura de diretórios que espelha a hierarquia do conteúdo ({matéria}/{frente}/{subject}/{título}/{arquivo}). Uma referência (FileContent) é criada no ms-simulado apontando para a chave do blob, e o status do conteúdo muda para Pending.

Etapa 3 — Revisão e aprovação
Um revisor com permissão validarDemanda acessa o conteúdo, visualiza o arquivo no modal e decide: aprova (Approved) ou rejeita (Rejected). Conteúdo aprovado fica visível; rejeitado pode ser resetado para Pending_Upload para reenvio.

Etapa 4 — Ajustes pós-aprovação
Existe um sistema de propostas de ajuste: qualquer usuário com uploadDemanda pode submeter uma versão corrigida do arquivo sem sobrescrever o original. O revisor analisa a proposta e, se aprovada, o arquivo principal do conteúdo é substituído pelo da proposta. Todo esse histórico é registrado no ContentFileHistory.

1.3 Permissões do sistema

Permissão	O que permite
gerenciadorDemanda	Criar demandas, deletar, resetar, reordenar, configurar frentes e subjects
uploadDemanda	Fazer upload de arquivos e submeter propostas de ajuste
validarDemanda	Aprovar ou rejeitar conteúdos e propostas

1.4 Analytics de conteúdo

Existe um job diário (cron à meia-noite) que registra um snapshot dos contadores de status (Pending_Upload, Pending, Approved, Rejected). Esses snapshots alimentam um gráfico de linha na página de analytics, permitindo acompanhar a evolução do volume de conteúdo ao longo do tempo. Há também uma visão agrupada por matéria/frente com os totais por status.

---

2. O que está bem

Pipeline editorial robusto

A separação de papéis entre quem cria a demanda, quem sobe o arquivo e quem aprova é uma escolha acertada. Em plataformas educacionais com múltiplos colaboradores, essa distinção evita que conteúdo sem revisão chegue ao aluno. O modelo é semelhante ao que sistemas de CMS maduros adotam.

Sistema de propostas de ajuste

O mecanismo de AdjustmentProposal é sofisticado e resolve um problema real: como corrigir conteúdo aprovado sem perder o histórico e sem criar caos. A proposta cria uma versão paralela que só substitui o original após aprovação explícita, usando transação de banco para garantir consistência. É uma das partes mais bem pensadas do sistema.

Auditoria completa

O ContentFileHistory registra cada troca de arquivo com fonte (upload inicial ou proposta aprovada), autor e data. Isso é fundamental para rastreabilidade em um ambiente com múltiplos colaboradores.

Hierarquia compartilhada com questões

Como mencionado, o fato de conteúdo e questões compartilharem a mesma árvore Matéria → Frente → Subject é o alicerce correto para a integração entre as duas entidades. Esse trabalho já foi feito na migração para o ms-simulado e não deve ser subestimado.

Reordenação manual

Existe um endpoint e uma interface para reordenar conteúdos dentro de um subject via drag-and-drop. Pequeno detalhe, mas importante para que os colaboradores possam sequenciar o material de forma pedagógica.

---

3. O que pode melhorar

3.1 A experiência de consumo do aluno é o ponto cego do sistema

Toda a atenção de design foi dada ao lado da produção (gestores, uploaders, revisores). O lado do consumo — como o aluno estuda o conteúdo aprovado — ficou em segundo plano.

Hoje, o aluno recebe um arquivo .docx para ler num modal do browser. Isso é problemático:

• Em dispositivos móveis, que são a principal forma de acesso do público da plataforma, a renderização de DOCX é inconsistente e frequentemente ilegível — fontes pequenas, tabelas quebradas, equações que não aparecem
• O DocxPreview no browser tem limitações conhecidas com formatação mais complexa, comum em material didático (fórmulas matemáticas, diagramas, tabelas com mescla de células)
• A experiência de leitura num modal não é a mesma de uma página de estudo — não há foco, não há navegação, não há marcação de progresso

3.2 Não há uma interface de estudo dedicada para o aluno

Analisando as páginas do client-vcnafacul, o fluxo de conteúdo existe no dashboard administrativo, mas não há uma página de estudo estruturada para o aluno. Falta uma tela onde o aluno entra, navega pela hierarquia (Matéria > Frente > Subject), encontra os conteúdos aprovados daquele tema e os lê de forma organizada dentro da plataforma.

Sem essa página, o conteúdo aprovado existe no banco de dados mas não tem um destino claro na jornada do aluno.

3.3 Formato único (.docx) cria fricção desnecessária

Aceitar apenas .docx limita bastante o que pode ser publicado e como é consumido. Materiais educacionais circulam em muitos formatos, e forçar a conversão para DOCX antes do upload cria trabalho extra para os colaboradores. Além disso:

• PDF renderiza perfeitamente no browser, é mobile-friendly e é o formato mais comum de apostilas e materiais educacionais no Brasil
• Não há suporte para conteúdo multimídia — vídeos, áudios, apresentações
• Não há suporte para conteúdo criado diretamente na plataforma (texto rico inline, sem arquivo)

3.4 A integração questão ↔ conteúdo ainda não foi construída

A migração para o ms-simulado eliminou a barreira arquitetural entre questões e conteúdo. Agora ambos compartilham o mesmo banco e a mesma hierarquia de classificação. Mas a integração ainda não foi materializada na experiência do usuário.

O caso de uso mais óbvio e valioso: quando o aluno erra uma questão de Funções Quadráticas no simulado, a plataforma poderia mostrar "Quer revisar esse tema?" e abrir diretamente o conteúdo aprovado de Funções Quadráticas. Esse link já é possível — os dados estão nos mesmos lugares — mas ainda não foi conectado.

Outros casos de uso que a coexistência no ms-simulado viabiliza:

• Recomendar conteúdo com base nas frentes com menor taxa de acerto do aluno
• Na criação de uma nova questão, sugerir conteúdos do mesmo Subject para o autor referenciar
• Mostrar, na página de um conteúdo, as questões daquele tema disponíveis para praticar

3.5 A demanda nasce de cima para baixo — o aluno não participa

O fluxo atual é: gestor decide o que produzir → colaborador sobe o arquivo → revisor aprova. O aluno é um receptor passivo de decisões tomadas internamente.

Não há nenhum mecanismo para que o aluno sinalize quais temas precisam de material, nem para que a plataforma oriente a produção com base em onde os alunos mais erram. A priorização do que produzir é, atualmente, arbitrária do ponto de vista dos dados.

3.6 Analytics medem produção, não aprendizado

Os snapshots diários e os gráficos de analytics respondem perguntas operacionais importantes: quantos conteúdos estão aprovados, quantos estão pendentes, como o volume está evoluindo. São métricas de gestão do pipeline.

Mas não há nenhuma métrica que responda: os alunos estão acessando o conteúdo? Quanto tempo passam lendo? Conteúdos de quais frentes são mais buscados? E a pergunta mais importante: alunos que estudaram o conteúdo de uma frente melhoram nas questões daquela frente nos simulados seguintes?

Sem essa camada, é impossível saber se o investimento em produção de conteúdo está gerando aprendizado.

---

4. Sugestões de melhoria

4.1 Curto prazo — melhorar o consumo sem mudar a arquitetura

Suportar PDF além de DOCX
É a mudança de maior impacto com menor esforço. PDF renderiza nativamente no browser com <embed> ou <iframe>, é responsivo, funciona bem no mobile, e é o formato em que a maioria dos materiais educacionais já existe. Bastaria adicionar .pdf como extensão aceita no upload e ajustar o componente de preview.

Criar a página de estudo do aluno
Uma tela /estudar organizada pela hierarquia Matéria > Frente > Subject, mostrando os conteúdos aprovados de cada tema. Design simples: lista de temas na lateral, conteúdo aberto à direita (ou tela cheia no mobile). Sem necessidade de infraestrutura nova — os dados já existem via endpoints disponíveis.

Melhorar o viewer de conteúdo
Independente do formato, o conteúdo deve abrir em uma experiência de leitura dedicada (página própria ou modal em tela cheia), não em um modal pequeno dentro do dashboard. Em mobile, deve ocupar toda a tela com scroll confortável.

4.2 Médio prazo — conectar questão e conteúdo

Link direto da questão errada para o conteúdo do tema
Na tela de revisão do simulado, ao ver uma questão que errou, o aluno vê: "Material de estudo disponível para este tema" → link para o conteúdo aprovado daquela Frente/Subject. A lógica é direta: pegar a frente da questão, buscar conteúdos aprovados com aquela frente, exibir o link.

Recomendação de conteúdo no dashboard
Com base nas frentes com menor taxa de acerto do aluno nos últimos simulados, o dashboard sugere: "Você tem dificuldade em Geometria Espacial — há 2 materiais disponíveis para este tema." Novamente, os dados para isso já existem no mesmo banco.

Conteúdo relacionado na página de estudo
Ao ler o conteúdo de um tema, mostrar na lateral: "Questões disponíveis neste tema" — permitindo que o aluno pratique imediatamente após estudar o material.

4.3 Médio prazo — conteúdo nativo (sem arquivo)

Além de arquivos, permitir que conteúdo seja criado diretamente na plataforma com o editor TipTap que já está instalado no projeto e em uso nas redações. Um resumo escrito inline, com formatação, imagens e links, seria mais acessível do que um arquivo DOCX, mais rápido de produzir para colaboradores, e muito mais fácil de consumir no mobile.

O modelo seria: conteúdo pode ter um file (como hoje) ou um body (texto rico armazenado como JSON/Markdown). Os dois podem coexistir — material complementar em texto + apostila em PDF, por exemplo.

4.4 Médio prazo — demanda orientada por dados

Cruzar automaticamente duas informações que já estão no ms-simulado:

1. Taxa de erro por frente/subject nos históricos de simulado
2. Volume de conteúdo aprovado por frente/subject

O resultado é uma lista priorizada de demandas: "Geometria Espacial tem 68% de taxa de erro e zero conteúdos aprovados — alta prioridade." Em vez de o gestor decidir o que produzir por intuição, o sistema orienta com dados. Essa funcionalidade poderia aparecer como uma sugestão na tela de criação de demanda ou como um painel separado para gestores.

4.5 Longo prazo — métricas de aprendizado

Registrar eventos de consumo de conteúdo: qual conteúdo foi aberto, por qual aluno, por quanto tempo. Com esses dados, é possível:

• Identificar quais conteúdos são mais acessados (e quais são ignorados)
• Correlacionar leitura de conteúdo com melhoria nos simulados seguintes
• Detectar conteúdos que têm baixo engajamento apesar de estarem aprovados (pode indicar que o material não está bom)
• Mostrar ao aluno o próprio progresso de estudo além dos simulados

---

5. Síntese

Dimensão	Avaliação atual	Caminho de melhoria
Pipeline editorial	✅ Bem estruturado	Manutenção e evolução incremental
Auditoria e histórico	✅ Completo	—
Hierarquia compartilhada c/ questões	✅ Fundação correta	Construir a integração em cima dessa base
Formato de arquivo	⚠️ Limitado (.docx)	Adicionar PDF e conteúdo nativo
Interface de consumo do aluno	❌ Inexistente como experiência dedicada	Criar página de estudo
Integração questão ↔ conteúdo	⚠️ Dados unificados, UX não conectada	Link direto questão → conteúdo
Priorização da produção	❌ Manual e sem dados	Demanda orientada por taxa de erro
Analytics de aprendizado	❌ Inexistente	Rastreamento de consumo

O sistema de conteúdo tem uma base sólida — a decisão de migrar tudo para o ms-simulado foi a certa, e o pipeline editorial está bem construído. O próximo ciclo de desenvolvimento nessa área deve focar menos em gestão e mais em consumo: criar a experiência de estudo do aluno e conectar o conteúdo produzido à jornada de quem usa a plataforma para aprender.