O Darwin Information Typing Architecture (DITA) é um modelo de dados XML padrão OASIS destinado a autoria e publicação (Wikipedia).
Confuso? Então vamos simplificar.
O processo de documentação em DITA é aquele em que a informação é dividida em pequenos tópicos que, por si mesmos, podem ser compreendidos. Cada um deles explica uma tarefa, um conceito ou uma referência em particular, e tem começo, meio e fim. É o que chamamos de redação baseada em tópicos, ou topic-based authoring.
A partir destes pequenos tópicos, são criados mapas que, basicamente, contém a sequência na qual eles serão exibidos ao usuário. Os formatos de exibição incluem o formato web (xhtml, html), documentos (.pdf, .rtf) e arquivos de help (Eclipse, JavaHelp, Oracle). Esses mapas incluem também tabelas de relacionamento que fazem com que cada um dos tópicos possa interligar-se a outros, formando referências entrecruzadas que melhoram, e muito, a navegabilidade do usuário online.
O padrão DITA é um padrão aberto, criado inicialmente pela IBM (2001) e aprovado como padrão OASIS em Junho de 2005. O padrão DITA é, em muitos aspectos, similar ao processo de adapatação evolucionária descrita pelo naturalista Charles Darwin, por permitir a adição de novos tópicos a cada nova versão de informação lançada, melhorando-a.
A melhoria contínua do conteúdo, a facilidade na geração de outputs diversos, e a forma extremamente estruturada de desenvolvimento da informação, fazem do padrão DITA (na minha humilde opinião) a fórmula perfeita para a geração de conteúdo técnico.
Se você gostou de tudo que leu até aqui e pensa em adotar o padrão DITA na sua empresa, é importante que você observe alguns pontos.
Tempo de adaptação
Escrever em DITA é algo que exige aprendizado e, sobretudo, adaptação. Existem vários editores de texto no mercado que permitem a produção de conteúdo em DITA, e basicamente escreve-se o texto aplicando-se tags que formatam o conteúdo a ser exibido. No entanto, o redator deve ser capaz de separar a informação em tópicos curtos, auto-suficientes. As frases devem ater-se ao que importa, evitando-se o uso de advérbios, adjetivos e adjuntos desnecessários. O autor deve deixar o “romance” de lado, indo direto ao ponto, sem rodeios. Um exemplo? Se seu redator costuma escrever “Hoje está um lindo dia de sol.”, ele terá que treinar o cérebro para dizer apenas “Faz sol.”, e isso leva tempo e treino… muito treino.
Adaptabilidade do conteúdo
O seu conteúdo deve ser passível de transformar-se em tópicos DITA. O primeiro processo então deve ser a avaliação de seus manuais, verificando se é possível manter sua coesão após a conversão. Cada tópico deve conter uma parte mínima do todo, como se fossem células formando em organismo maior. Eles devem fazer sentido tanto isolados quanto em grupo, e portanto seu time deve ser capaz de montar mapas que apresentem a informação de maneira que ela possa ser lida e compreendida. O reuso também é importante – identificar quais partes da informação podem ser generalizadas e então reutilizadas em diferentes níveis torna-se inevitável em DITA, pois uma de suas melhores características é o reuso da informação.
Armazenamento e padronização
Invista no armazenamento de sua informação. De nada adianta todo esse esforço se sua empresa não for capaz de rastrear e manter esses tópicos de maneira adequada. Ferramentas de gerenciamento eletrônico de conteúdo, como o FileNet, são um bom exemplo. Através deles você será capaz de armazenar seus arquivos, gerenciar versões, e até interagir de maneira a criar pacotes que possam ser publicados através de scripts padronizados, ou enviados para teste e/ou tradução automaticamente.
Ainda nessa linha de pensamento, a padronização da linguagem utilizada por seus redatores, a maneira como certos tipos de informação serão apresentadas, quais tags serão utlizadas em quais situações, e até mesmo a nomenclatura dos seus arquivos DITA, devem ser padronizados e conhecidos por todos. Então invista na definição de padrões e sua conseqüente disseminação dentro do time.
Com tudo isso, você pode pensar – ah, muito trabalho! Sim, você tem toda razão. Mas, acredite que o retorno em termos de facilidade de alteração de conteúdo, variedade de formatos e publicações, melhoria de interação com clientes e usuários, rapidez no time-to-market, entre outros itens, valem cada centavo e minuto gastos.
Nada se compara a trocar o nome do produto num arquivo conref (content reference) e vê-lo automaticamente mudar em todos os seus tópicos ao mesmo tempo. Ou pedir ao seu redator que monte um PDF somente com informações de troubleshooting e receber o livro pronto no mesmo dia. Ou poder determinar, no momento em que o tópico é escrito, que partes da informação não devem ser traduzidas.
As possibilidades são infinitas e ficam melhores e mais confortáveis conforme sua equipe torna-se mais especializada no assunto. Então, porque não tentar à maneira de Darwin?
Sou pós-graduada pela FGV em Gerência de TI. Já fui programadora, tradutora, revisora, e atualmente sou redatora técnica há mais de 11 anos. Aprendi inglês muito nova, e descobri a redação técnica meio que por acaso, através de um anúncio de multinacional que precisava de alguém que escrevesse bem em português e inglês e tivesse disponibilidade para viagens. Lá trabalhei por 7 anos, viajei por todos os continentes, aprimorei técnicas, e entrei em contato mais profundo com o ciclo de vida do desenvolvimento de software no Brasil. Hoje sou líder de desenvolvimento de informações na IBM, onde planejo os projetos de documentação do produto sob minha responsabilidde, desenvolvo conteúdo, reviso materiais, dou treinamentos, mentorizo equipes mais novas e auxilio no processo de globalização e de teste da interface com os usuários finais. Espero trazer a vocês bons insights sobre o mundo da documentação em TI.
You must be logged in to post a comment.
