A long time ago people were talking about electronic document circulation. Only, so far (for example) in my office, to prepare a single document, 2-3 sheets of paper go to drafts.
Some advanced bosses take all the documents that they have to sign, accept for review, first in digital form, put marks, extract their changes in color ...
And somewhere, entire departments work together on several documents, passing them to each other in a circle. "You enter your information in the table, while I will make a list, and then we will change and check it ..."
')
And again, my programmer-rationalization nature combed, stirred; you can make it easier for people to live and work in the world! Some of their actions can be automated, for others there are even ready-made solutions!
So what am I proposing?
- Decision.
- Application.
Solution: OpenDocument + Subversion + Visualizer diff + Trac
- OpenDocument format ( ODF ).
The format of office documents of various kinds. It is used in open office suites OpenOffice.org , StarOffice and others .
The peculiarity of the format from the point of view of the developer is that each document is an archive, the main part of which is occupied by files in XML format . The archive is unpacked on the fly, and the XML files are easily programmable.
- Subversion version control system.
Version control systems ( WOS ) use so-called differential compression for storing many versions of a single document (sometimes the term delta compression , or Δ-compression, is sometimes found). Due to the differential compression in a special repository - repositories - files are not fully deposited, but only the differences between the versions.
These differences are usually calculated using the diff program (from the English. Difference - the difference ). The user of the CWS can at any time compare any versions of the document, find out what revisions were made by him and other users.
return to any of the previous document states.
- The diff visualizer.
Diff utilities, old as the computer world, have 2 significant drawbacks. First, it is designed to compare text files line by line, which may not be optimal for finding differences in XML files.
Secondly, how different an ODF document in edit mode is to its original XML code, diff output is just as incomprehensible to the end user. To work effectively, the user needs a visual representation of the differences between versions.
Perhaps this is the only component of the proposed system that requires serious effort.
Possible solutions to the problem:
- processing the output of the “classic” string diff;
- Refinement or creation of a new diff to more correctly compare XML files and simplify the visualizer.
- Job Management System.
There are various job management systems ( CPS ), but so far I have only been well acquainted with Trac .
CPS Trac allows you to create tasks, assign them to users, specify which group of documents is affected by the task, track the status of the task, get information about the work of users on tasks and much more.
Application
Consider now the mechanism of the work of this whole bunch
The theater begins with a hanger, a house from the door, and a software system that claims that a person can work with it begins with a user interface. In my electronic document management system, the user directly deals with the document and the office program (word processor, spreadsheet, etc.), as well as the
control system interface implemented as a separate application or, preferably, as a website on the corporate intranet.
Let us take, for example, the following situation: the head of a branch of a certain firm gives a task to some department to prepare an annual report. For that he
- enters the corporate website, in the KMS ;
- creates a task in it;
- sets the job attributes:
- deadline for the assignment;
- importance;
- urgency;
- appoints the executor of the task - the head of the department.
The task is entered into the system and automatically sent to the head of the e-mail department or using the corporate instant messaging system (
EMS ).
The head of the department indicates a list of employees related to the assignment.
Each employee writes his own part of the report and from time to time sends it to the version control server.
There are many ready-made solutions for this, but to make it more convenient for the user, you can even write a plugin for OpenOffice.org and other office suites.
When sending a document version to the server (
committing changes in the terminology of the
CWS ), a notification about the changes made is automatically sent to the head of the department (and to all those involved). He can immediately view the change in a convenient way and make his own adjustments. It is not necessary to highlight their changes in color or in any other way. Simply write what should be in the end. Diff will find and show all edits and notes.
At the end of the report preparation, the performer - the head of the department sets the status of the task to “completed”
If the branch manager for some reason does not like the task, he can again make the task active (with an indication of the reason).
UPD. Thanks to
Outspector for the informative
comment . He recalled such an important issue as version merging, and suggested using L
A T
E X for documentation preparation. It is necessary to agree with SW. Outspector about the usefulness of L
A T
E X for specialists, but a good solution for the “secretaries” has not yet been found.