Ir para o conteúdo principal

Autonomia do DIOF no tratamento da formatação das matérias publicadas

OBJETIVO

Melhorar a autonomia do DIOF em relação a formatação das matérias, através da criação de funcionalidades necessárias para que a necessidade seja atendida. Pois atualmente o Diof recebe matérias de ultima hora para serem publicada no mesmo dia, e quando existir matérias fora do padrão pré-estabelecido de formatação a equipe técnica do DIOF poderá ajustar a formatação da matéria de forma correta sem comprometer o conteúdo.

VISÃO GERAL

Atualmente a grande maioria das matérias vem do Sistema Eletrônico de Informações - SEI, esse recurso facilita o dia-a-dia dos servidores, principalmente pelo fato destes conseguirem publicar sem sair da plataforma, isso decorre por meio de uma integração ativa entre o PPE e o SEI.

No entanto, devido essa integração entre os sistemas, existem alguns fatores que estão causando problemas em relação à formatação das matérias. A primeira situação a ser analisada é que pelo fato do sistema SEI ser externo e também ser uma plataforma extremamente restrita a alterações no seu código, impossibilita a realização de alterações ou criação de padrões dentro desse sistema.

Logo essa situação relatada cria um cenário onde não existe uma forma de controlar o que os usuários criam no editor de texto do SEI, pois não existe um padrão pré-definido ao qual o sistema PPE possa utilizar como parâmetro para entender, ter controle e até mesmo realizar ajustes automatizados utilizando padrões de classes css e formatação em geral do conteúdo que é gerado por exemplo. 

POSSÍVEIS PROBLEMAS

Portanto hoje em dia fica totalmente na responsabilidade do usuário criar uma matéria nos padrões especificados pelo Diof. Algumas adaptações e formatações automáticas são realizadas pelo PPE, ocorrendo estas a partir de uma matéria agendada, onde é identificada alguns padrões de classes css, e  então ocorre uma reescrita das mesmas classes automaticamente através do sistema PPE, a fim de estabelecer uma padrão desejado pelo Diof.

Entretanto esta ação não cobre todos os problemas, isso porque se o usuário cometer um erro durante a criação da matéria, não há como ajustar, sendo necessário criar um novo documento. Esta situação acarreta em um imenso processo burocrático, principalmente quando a matéria já se encontra assinada.

O Diof desde o principio queria interferir nesses casos, e de alguma forma poder realizar a editação. Porém existe o fato relacionado a integridade do conteúdo das matérias, logo sendo assim ao permitir que o Diof ajuste a formatação, deve ser criado mecanismos que vão garantir a integridade do conteúdo da matéria.

SOLUÇÕES

Uma das soluções que podem ser implementada dentro da plataforma PPE é o dar autonomia para usuários autorizados do Diof poderem interferir nas matérias ou no diário como um todo em relação a sua formatação, porém mantendo a integridade do conteúdo.

Um caminho para alcançar esse objetivo seria realizar a interferência por matéria, onde o usuário responsável pela administração da plataforma PPE iria extrair o conteúdo da matéria a qual se encontra formatada de forma incorreta e em seguida envia-la para o editor da plataforma GovDoc, na qual seriam realizados os ajustes devidos na formatação. 

Com os ajustes realizados e salvos na plataforma GovDoc, o sistema PPE ficaria responsável por detectar se houve ajustes na formatação, e quando o resultado for verdadeiro o mesmo ira renderizar a matéria consumindo as informações do GovDoc o qual foi utilizado para formatar a mesma, as demais seguiriam o mesmo fluxo definido atualmente.

CONSIDERAÇÕES FINAIS

Tecnicamente a matéria formatada ficara salva no GovDoc e durante o processo de renderização do diário as informações vão ser consumidas de lá, mais especificamente as matérias que estiverem com a condição materiaFormatada como verdadeiro. E em questão de integridade, o GovDoc ira garantir que o conteúdo não seja manipulado, sendo apenas possível realizar a alteração na formação. 

RESPONSÁVEIS

  • Alexandre Santos Freire (Analista de Desenvolvimento);

  • André Henrique Cortez (Analista de Desenvolvimento Full-stack);

  • Denise Jeane (Product Owner);

  • Jorge Luiz de Jesus Paiva Junior (Analista de Desenvolvimento Full-stack).

GLOSSÁRIO
  1. Product Owner: O Product Owner representa os interesses de todos os envolvidos, define as funcionalidades do produto e prioriza os itens de Product Backlog. Fonte: (https://www.trt9.jus.br/pds/Scrum/roles/product_owner_10E7BD3.html).
  2. Product Backlog: É uma lista priorizada, contendo breves descrições de todas as funcionalidades desejadas para o produto. Fonte: (https://www.culturaagil.com.br/product-backlog-o-que-e/).
  3. Scrum Master: O Scrum Master é o membro do time que detém, em geral, maior conhecimento sobre o Scrum (“framework que ajuda as equipes a trabalharem juntas”). Logo, ele é responsável por potencializar o trabalho da equipe. Fonte: (https://www.voitto.com.br/blog/artigo/scrum-master) (https://www.atlassian.com/agile/scrum).
  4. Framework: Estrutura é feita para resolver um problema específico. Fonte: (https://www.lewagon.com/pt-BR/blog/o-que-e-framework).
  5. Full-stack: O desenvolvedor Full-stack é aquele que pode atuar em qualquer etapa do desenvolvimento de sistemas. Fonte: (https://www.proway.com.br/blog/dev-full-stack-o-que-e-isso)
  6. CSS: Sigla para Cascading Style Sheets, ou seja, Folhas de Estilo em Cascatas, é utilizada na estilização de componentes escritos em linguagens de marcação. Fonte: (https://br.godaddy.com/blog/voce-sabe-o-que-e-css-entenda-como-funciona-e-para-que-serve/)

Estudo Técnico – 07/02/2022

 

 

Voltar ao topo