Patent Application
20080177782
Success has many fathers, and so does the modern document: many, scattered authors write it, between them. No tool is truly good at supporting such work. Today's software has all evolved from a weak single-user approach. Over decades, for most users ‘Track Changes’ (introduced by Microsoft in Word98) has been the only noticeable advance. This works well for a pair of writers, who exchange successive versions of a single copy, rarely keeping more than one open. A moved sentence or paragraph or section hides any rewriting within it—the whole block of text is all marked as ‘changed’—but there is no collation problem.
When a larger group of authors work on changes, versions always proliferate. A common strategy is to plan that the draft goes from group member Anne to member Bill to Connie, . . . , in sequence, each making changes. ‘Track Changes’ supports this model to the extent of showing each contributor's changes in a different color, and lets a change be accepted or rejected (by whomever has the document open: there is no ‘authority to accept/reject’privilege for the prime editor). A unique physical document, going from desk to desk to desk, would—and in pre-digital days, often did—enforce this workflow, at the expense of putting every author on the critical path. Any absence or overload for member Dave delays Estelle, Fred, and so on to the end of this drafting round, and to the final appearance of the document. This is far too slow for modern conditions, and also prevents parallel work by members from different disciplines. (A CTO and CFO may both need to see an entire document, as may a physician and a social worker, but they make changes in largely disjoint sections.)
In a digital world this model is unacceptable, unenforceable and unaccepted. Busy collaborator Dave gets to the document when a timeslot opens, passes it on, . . . and soon afterward, thinks of new additions or changes. Since Dave still has a soft copy of what went off, he edits the new thoughts into it without waiting for the next editing round, and mails it (to Estelle, to the main editor, or to the whole group). The new version has changes that are missing from what has now been seen by Estelle and by Fred, and lacks changes that Estelle and Fred have since made. There is no longer a unitary, evolving document. Soon there is a plethora of versions. Collating and merging them into a final document (or a single start-of-next-round document) becomes a painful, laborious task, with many opportunities to miss useful changes or to offend a member who sees the same typo over and over again, and corrects it each time. ‘Track Changes’ simply cannot handle this multiplicity.
Even where members work in the same building, it is hard to schedule a meeting for three or more people to harmonize versions, with line by line discussion. Today's groups are scattered up to twenty-three time zones apart, and a time convenient to all is even harder to find.
We note that Microsoft Word does have a ‘compare and merge documents’ tool. Suppose a document contains the sentence “The best method on the market today is a catheter,” amended by one author to “The best method on the market today is a catheter, which sucks” (which is indeed among the things that catheters do) while another has given “The best method on the market today is a catheter, which does not directly assess volume”. Then, merging the first with the original and then merging the second yields “The best method on the market today is a catheter, which sucksdoes not directly assess volume”. A more usable and structured approach is sorely needed.
A more acute version of the harmonization problem arises where the ‘text’ is a computer program, with different members working on different modules. Minor inconsistencies among assumptions applied to different sections can easily crash the entire application, or even prevent it from compiling. This has led to an industry of ‘version control’ software such as (sampling those running under Windows) Visual SourceSafe, ClearCase, abCVS, CWPerforce and Alienbrain. Some programmers can fit themselves into the discipline of using one of these, since they appreciate the logic and learn its elaborate procedures for detailed control. Many more programmers fail the discipline, or resist it. Few non-programmers can even understand the rules.
This is the natural work flow that multiple collaborators fall into. It is not easy to impose change on it. Nor is successfully imposed discipline necessarily a good thing for the text. Co-authors need to work in the times available to them, with the materials available to them up to that point. “Checking out” a document, with a locking arrangement so that nobody else can change it until it is “checked in” again, blocks the authors from parallel use of time. Checking parts in and out separately allows some parallel effort, but incompletely so, with a troublesome interface and serious annoyance to users. (You may need to cross-check with a statement in another section, even one that is not your responsibility to edit, so you need at least “read” access. If you spot an obvious typo while reading a write-locked section, you must make a note or send a message to the person who has it open, or something else equally tedious.)
It is better, particularly in an unstructured setting, to support the natural process than to attempt to supplant it. The natural process does have its difficulties:
The creators of 101, 102 and 103 simply worked on the single document on hand when they started; the creator of 104 knew (how?) that 100 could be ignored, and missed the appearance of 103 after he started work; 105 likewise took 100 as superseded, but used 101, 102 and 103 (104 coming too late); then 105 and 106 correctly ignored anything before 104 and 105. Problems arise:
Problem (a) is answered partly by users looking back over e-mails, and asking other authors: this is a poor solution, and progressively harder as the collection of versions grows. Problems (b-e) require ‘eyeballing’ the texts, and often spreading out hard copy on a real desk-top (not stacking narrow window viewports on the small display area of a typical computer). Problem (f) usually requires ‘cut and paste’, and is error-prone. Grappling with a piece of 12-point text in the Arial font copied into an 11-point Times-Roman paragraph and appearing as 10-point Garamond (a font present in neither file), one may easily be too busy compensating for a word processor's bugs to detect one's own mistakes.
The purpose of the present invention is to simplify the answers to problems (a-f).
The general objective of the present invention is to enable collaborating authors to make use of the multiple versions they create between them, without adhering to a rigid scheme of version control or missing any suggested change by mistake, but assisted in harmonising different revisions. This is achieved by making the software (not the users) responsible for determining which revision has taken which into account, by comparison of version content rather than by a record-keeping protocol to which users must adhere.
In an embodiment of the present invention the method assembles versions of a document or group of related documents, typically from multiple creators, decides by string comparison algorithms and version date (rather than a record of changes) which version takes account of which other versions, and to present to the creator of a new version those differences which that creator needs to know about.
If the creator has saved or uploaded a version which contains segments originating in an earlier version, the creator is presumed to have seen the said earlier version or a version derived therefrom, and thus not to need to revisit it. The first version to repeat such a segment is considered to have direct descent from the originating version, and the directed graph whose edges are formed by direct descent relations is the descent tree of the versions.
In a father embodiment of the present invention the method shows to the user which versions are judged to be relevant to that user, by distinguishing them visually from the others in the assembly. This may be achieved by a different coloration of the identifiers of the said versions or of their background, or by a different typographical format, size or font, by the visible difference of leaves in a displayed descent tree, by presenting them in a separate list, or by numerous other means that will be evident to one skilled in the art.
In a further embodiment of the present invention the method judges which versions are relevant to that user by identifying the leaves on the descent tree.
In a further embodiment of the present invention the method permits the user to modify the set of versions considered relevant to that user by adding or excluding individual versions, in our preferred embodiment by clicking on their representations in the display.
In a further embodiment of the present invention the method optionally includes among the group of versions relevant to that user a Working Copy, which may be the version file most recently created by the user, or the oldest file in the group, or the most recent version issued as a draft by a designated Moderator, or selected by the user.
In a further embodiment of the present invention the method provides a group of one or more collaborators with web access to the assembled versions, such access to include the ability to add versions and supplementary material to the assembly, to download or open files or sets of files in the assembly.
In a further embodiment of the present invention the method enables a user who has opened one or more files in the assembly to edit said files using tools provided by the embodiment of the invention, and to save the results as new versions without overwriting the earlier versions or inventing new file names.
In a further embodiment of the present invention the method enables a user who has downloaded one or more files from the assembly to edit said files using editing software provided by or external to the embodiment of the invention, and to upload the results as new versions without overwriting the earlier versions or inventing new file names.
In a further embodiment of the present invention the method enables a user to upload or download a file or set of files between the assembly and a local file system, by a ‘drag and drop’ operation.
In a further embodiment of the present invention the method displays to the user the differences found by string comparison.
In a further embodiment of the present invention, where the user opens the files over the web, the method presents the said files as an integrated display that shows the differences found by string comparison.
In a further embodiment of the present invention the method may show the said integrated display by using a separate window to represent each version shown, with lines and other graphical devices marking their relationships.
In a further and preferred embodiment of the present invention the method may alternatively show use a single window to represent all the versions shown, without multiple display of identical text.
In a further embodiment of the present invention the method displays substantial repetitions detected by string comparison within a file.
In a further embodiment of the present invention the method uses variable compression of the text to show differences or repetitions in context.
In a further embodiment of the present invention the method enables the said variable compression of the text to be modifiable by user input.
In a further embodiment of the present invention the method enables the user to select among the variant readings offered by different versions, by clicking on elements of the display, and to edit the text directly, so creating a new version.
In a further embodiment of the present invention the method displays to the user each instance of repetition revealed by string comparison, so that the user may select which copy or copies of a repeated segment are to be retained and which deleted, or to mark the repetition as permanently accepted (in which case it will not be presented again to that user).
In a further embodiment of the present invention the method enables one of the group of collaborators to be designated as Moderator, with authority to issue as a numbered draft a version that supersedes all those previous to it.
In a further embodiment of the present invention the method displays the acceptance or rejection by other co-authors or the Moderator of changes made by a user in that user's immediately previously submitted version, or in all that user's previously submitted versions, together with reasons given in comments for such acceptance or rejection.
In a further embodiment of the present invention the method displays the history of adoption or rejection of all a particular user's changes, optionally including attention drawn to the rejection of repeated or near-repeated changes, over the full descent of the document.
In a further embodiment of the present invention the method enables either any member of the group of collaborators, or the Moderator alone, to invite other persons to join the group, such invitation being honored by the embodiment of the invention.
Embodiments of the present invention will be described more fully hereinafter with reference to the accompanying drawings, in which embodiments of the invention are shown. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Like numbers refer to like elements throughout.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” “comprising,” “includes” and/or “including” when used herein, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. It will be further understood that terms used herein should be interpreted as having a meaning that is consistent with their meaning in the context of this specification and the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.
The present invention is described below with reference to block diagrams and/or flowchart illustrations of methods, apparatus (systems) and/or computer program products according to embodiments of the invention. It is understood that several blocks of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, and/or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer and/or other programmable data processing apparatus, create means for implementing the functions/acts specified in the block diagrams and/or flowchart block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instructions which implement the function/act specified in the block diagrams and/or flowchart block or blocks.
The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions/acts specified in the block diagrams and/or flowchart block or blocks.
Accordingly, the present invention may be embodied in hardware and/or in software (including firmware, resident software, micro-code, etc.). Furthermore, the present invention may take the form of a computer program product on a computer-usable or computer-readable storage medium having computer-usable or computer-readable program code embodied in the medium for use by or in connection with an instruction execution system. In the context of this document, a computer-usable or computer-readable medium may be any medium that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
The computer-usable or computer-readable medium may be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium. More specific examples (a non-exhaustive list) of the computer-readable medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, and a portable compact disc read-only memory (CD-ROM). Note that the computer-usable or computer-readable medium could even be paper or another suitable medium upon which the program is printed, as the program can be electronically captured, via, for instance, optical scanning of the paper or other medium, then compiled, interpreted, or otherwise processed in a suitable manner, if necessary, and then stored in a computer memory.
The history of changes becomes arbitrarily complicated as soon as more than two authors/editors are involved. A record made of what a user does can catch only a binary change, between the previous and new versions on this user's computer. It is complex to reconstruct from a collection of such records the differences between all current versions, with the (potentially competing) mergers that feed several ancestors into one, and the (potentially competing) revisions that make several versions out of one. Even gathering together such change records into a history network would normally require that they be made in a standardised format, forcing the authors to use shared software that not only records the changes, but connects the versions by a unitary system of ID markers.
Further, if a user changes version V1 by importing a paragraph from version V2 (thus creating V3 or higher), at the text level the obvious change to record from V1 is just that a paragraph P has been inserted. The ‘cut and paste’ mechanism supported by most operating systems, which copies a section into a buffer and then into another file, does not support even recording a record of an ID for the source document. Much less does it support transferring change records associated with P, recording modifications which another user made from the form of the same paragraph in an earlier version V0. A third user looking at the modified version of V1 thus does not know of these differences, and must refer back to V0 and V2 to find them. To change this requires the use of a common change-mark-up scheme across all documents, and a ‘cut and paste’ mechanism that preserves these marks, as the Windows mechanism attempts with imperfect success to do for format marks (bold, italic, color, font, size, etc.). If a group includes users with Windows, MacOS and Linux machines, with widely-used editing software such as MSWord, emacs, OpenOffice and PDF Writer, such a common framework is unavailable.
Such a framework may be enforced within one corporation, but when (for instance) the document is a contract involving two or more companies, and a law firm for each company, no writer wants to change habitual editing software for a single document. A multi-writer solution using change records would require global office software hegemony to even start. It would tend to lead to rigid tools, hard to modify with user feedback, and a user interface (UI) that aims more to display changes as actions than as results. (In Word, a change from “The brown quick fox” to “The quick brown fox” can be made in two ways—drag “brown” to the right, or drag “quick” to the left—and is displayed as “The brown quick brown fox” or “The quick brown quick fox” accordingly, though the final result is identical, and though the visual difference is irrelevant to the next user. This clumsiness is not logically forced by change tracking, but in programming practice as in geopolitics, means do shape ends.)
In contrast, then, the present invention exploits direct comparison between all documents submitted to the system as part of the same project. In our preferred embodiment this system runs over a web-style network (either the open ‘world wide web’, or an intranet), with files transferred between individual computers. We describe it primarily in these terms, but it will be evident to one skilled in the art that simple modifications would enable it to operate—for example—on a central ‘main frame’ computer which retains files, and which all users log into when they wish to modify a file. Other modifications would enable it to operate on the computer used by one member of the group, with email attachment of files rather than web sharing.
Certain applications of the invention, detailed below, are helpful even to a single user independently of any group, and a version supporting these could be implemented as a stand-alone application on an unconnected computer.
Recent decades have brought fast algorithms for string comparison, notably aimed at DNA sequences, as in S Needleman and C Wunsch, A general method applicable to the search for similarities in the amino acid sequence of two proteins, J. Molec. Biol. 48(3): 443-53 (1970), and the variant of their algorithm described by T F Smith and M S Waterman, Identification of Common Molecular Subsequences, J. Molec. Biol., 147:195-197 (1981), which is more sensitive to local alignment without requiring a global match. (In both chromosomes and text, long sections may be transposed, during evolution and editing respectively.)
Such algorithms, and work on running them faster such as A Wozniak, Using video-oriented instructions to speed up sequence comparison, Comput. Appl. Biosci. 13(2):145-50, 1997, S Kurtz, A Phillippy, A L Delcher, M Smoot, M Shumway, C Antonescu, and S L Salzberg, Versatile and open software for comparing large genomes, Genome Biology (2004), Genome Biol., R12.1-R12.9, A L Delcher, A Phillippy, J Carlton, and S L Salzberg, Fast Algorithms for Large-scale Genome Alignment and Comparison, Nucleic Acids Research 30, 11 2478-2483 (2002), and A L Delcher, S Kasif, R D Fleischmann, J Peterson, O White, and S L Salzberg, Alignment of Whole Genomes, Nucleic Acids Research, 27:11 (1999), 2369-2376, make it practical to process any pair of sequences and find both shared parts, and differences within those parts. It is now common to test a gene against a large body of DNA data, to find genes that are approximately the same, or approximately share subsequences at practical speeds: for example (see http://mummer.sourceforge.net/), one can find all 20-basepair or longer exact matches between a pair of 5-megabase genomes in 13.7 seconds, using 78 MB of memory, on a 2.4 GHz Linux desktop computer. The text in a typical collaborative document contains considerably fewer data—about a megabyte per 500 double-spaced pages—so that full text comparison of versions is highly practicable. (A document is often a multi-MB file, but in these cases most of the size is due to embedded images. The present invention does not seek to compare images, but including their names and sizes in the comparison process can detect many changes in illustration as well as in text.)
There are many analogies between text matching and DNA matching. For example, chromosomes have many stretches called ‘junk DNA’ because they do not code for amino acid sequences in proteins (the sequence for one protein has come to be called ‘one gene’, so junk DNA is not in genes). Some of this may control the elaborate, multi-level way in which DNA coils, and the 3D chromosomal structure which enables the cell access to any gene that its dynamic wishes to express: if so, it is more like XML mark-up than ‘junk’. However, from the direct content point of view it includes long sequences of identical repetitions, with easily mutating lengths. For protein comparison purposes one wishes to ignore these length differences, and the algorithms used allow for this. The analogy here is with whitespace, whose length often changes by cut and paste, by different prejudices of writers (some insist on a double space between sentences) or different software. (LATEX treats any whitespace sequence, including at most one new-line, as one whitespace token. Software that saves a LATEX file may write whitespace sequences quite different from those it read, without creating a content or format difference of interest to the user.) The molecular biology matching rules that ignore differences in the length of repeat sequences adapt directly, for one skilled in the art, to text matching rules that ignore differences within whitespace.
In the final version, published or distributed, of a document, white space details make a difference to the look. But a group of co-authors will usually do a less good job of adjusting those details to a neat, homogeneous look than any one co-author would do alone, and concentration on content over layout in the collaborative stages will make them more productive. Our preferred embodiment, therefore, suppresses differences of whitespace length, vertical gap height between paragraphs, etc., when comparing drafts.
An alternative approach to comparison exploits the hierarchical structure of the texts, which almost always includes at least sentences and paragraphs, and often chapters, sections, subsections, etc., at multiple levels. (No such straightforward structure has been identified in chromosomes, though there is a suspicion that some of the ‘junk DNA’ has a somewhat analogous organisational function.) A preliminary comparison can exploit this for efficiency, since for example a sentence or paragraph in file A which perfectly matches a sentence or paragraph in file B must match it, in particular, at the ends. Consequently, a search for perfect matches can discard many candidates quickly, by the failure of agreement at the start or the end, decreasing the time taken to find all the perfect matches. This in many cases means to find a large fraction of the overall matching structure, so that less effort is needed in finding the remaining imperfect matches. However, this is an issue of algorithmic performance, since the overall matching description sought is the same in either case: the core of the present invention is the fact that such a description can be found (and found fast enough to be useful), together with means of exploiting this description. A preferred first embodiment is thus to adapt the highly optimized forms already achieved for the algorithms current in molecular biology, without changes that could sacrifice that optimization. (Analogously, in principle N bytes (octets of 0s and 1s) can be used with less computation than N binary 32-tuples; but with byte data on a 32-bit processor, it is better to expand the bytes to 32-tuples unless the computation can pack them in groups of four and combine the byte arithmetic into recognized 32-bit operations, which requires research and ingenuity. Re-use of optimized resources can out-perform a superior method that is not yet optimized.) We expect later embodiments of the invention to exploit more fully the available structure.
The invention, then, is of a system which stores a cluster of documents related by history and optionally by interdependence, each in one or optionally more sections. These are handled as distinct versions of one or more files such as ‘business plan’, ‘elevator presentation’ and ‘press release’, and perform comparison, presentation and manipulation operations to be described more fully below. We refer to this cluster as a Work In Progress, or WIP, and to the system provisionally as OmniPad. Before describing the interaction workflow, we disclose the underlying comparison processes. An important goal is to detect document relationships automatically, rather than rely on record-keeping by human users with disparate backgrounds and low motivation for training. It is important to note that a co-author may edit a document within OmniPad, but may also receive a version by download or email attachment, work on it with locally installed software, and return an edited version (called below a ‘proposal’). Since the co-author may receive it as—for example—getHappy.doc and return it as getHappyB.doc, while another may even send back beGlad.doc, file names are insufficient in tracking document identities.
When a new file is entered in the WIP, OmniPad immediately performs string comparison between its content, preferably including but not necessarily limited to
file names and other available data related to embedded images, though not the images themselves
We note that not all mark-up systems are fully mutually translatable: for example, equations written in a document using the LATEX system cannot be well reproduced in the more limited representation available in MSWord, though translators exist (for example) between LATEX and MathML. However, an interdisciplinary co-author sometimes finds it necessary to recreate a LATEX document ‘fubar.tex’ as ‘fubar.doc’, for a TEXnically unequipped collaborator, publisher or patent attorney. Continuity should not be lost to OmniPad for such a reason. The string-matching code in our preferred embodiment therefore tags mathematical sections as a special class of difference, allowing a user to check them visually or for the moment ignore them. This requires recognising that “for a less than 3” in Word (using only italic and font markers) and “for $a$ less than 3” in LATEX (which explicitly tags mathematics mode with the $ sign) have such a correspondence, as do “for a1 less than 3” and “for $a_{l}$ less than 3”. An ideal embodiment would spot that “a1” matches “$a—{1}$” exactly in final effect, that “a1” matches “$â1$”, and not vice versa: but in our currently preferred embodiment (for reasons of simplicity) it is enough to tag those literal string differences that may arise only as a change of representation. A check on mathematical expressions can be called out as a separate human task.
An important use of comparisons is to model ‘descent’ among files, as in
In
It is harder to tell whether 202 has been fully taken into account, with all changes made there either accepted or rejected. The creator of 203 may for example be interested only in the market analysis part of the evolving document, and ignore completely the engineering section. The collaborators may reduce this problem by breaking the WIP into a cluster of documents, one for each section: optionally an embodiment of the invention may support this, by for example providing for an over-file which lists the parts to be included. This however becomes somewhat format-dependent: LATEX, for example, contains such a mechanism already, while many widely used commercial formats do not, or—with similar results—most users do not know about it. An implementation of such a mechanism within the present invention would force all co-authors in the group to use the present invention directly if they wish to display or print the fully-assembled document. Since it is desired to allow the present invention to be used only by those members of the group who so choose, rather than hold the group to the e-literacy level of the least sophisticated member, such an over-file should be optional rather than a mandatory tool. Another abatement of this ‘partial use’ problem lies in the ‘My changes’ and Change Log features below.
In a first embodiment, then, version 202 may be labelled as ‘no longer relevant, to those who have seen 203’; in a graph like
The use above of a sentence as the unit 211 of evidence for text derivation is purely exemplary, as is the matching of it to a gap 210. One could use a larger or smaller unit, or a sentence which it changes rather than a gap, but it is necessary to set a minimum degree of change. In a recent example of a document edited by one of the present inventors, both he and another author independently changed
We refer to the directed graph whose nodes are versions and whose edges are given by direct descent in the above sense as the descent tree. If a version has no other version with direct descent from it, it is a leaf of the descent tree. (Note that this directed graph is a tree as in the usage ‘family tree’, not necessarily in the graph theoretic sense that disallows multiple paths between a pair of nodes.
A version stored within the control of OmniPad may be stored simply as a sequential file, or space may be saved by storing it as a list of incremental differences from some other version (a difference base), from which it can be reconstructed as needed, by means familiar to those skilled in the art. This is comparable to saving animation frames as a sequence of differences, rather than waste memory on unchanged pixels. It has storage advantages, and also speed, since a difference can be stored faster than a file, permitting essentially continuous back-up, particularly valuable in a web service, such as is intended as a major use of the present invention. The user does not see a list of intermediate file versions, and for space reasons these are not maintained as separately stored files, but each time a unit task is performed a new and potentially accessible version is created. (A unit task may be defined as the uninterrupted insertion/deletion of a word, alternatively of a contiguous string of text, or as any textual change that cannot be more compactly described as a combination of smaller changes.) In conventional editors, for either text or images, such a record is used only to step back globally through the changes: in PhotoShop™ for example, if one selects, paints, and rotates part of an image, each of those states is listed separately in a history palette. One can then select any of the states, and the image as a whole reverts to how it looked when that change was first applied, and new work can be started from there. It is however impossible to restrict such reversion to one or several layers, or image regions. Similarly in Microsoft Word, the Ctrl-Z Undo command steps back through changes, but cannot be limited to a particular paragraph or substring. If “Track-Changes” is turned on, one can move more selectively, but not (for instance) compare an edited-and-then-moved paragraph with its earlier state, without moving it back.
This is an implementation choice and should not be visible to the user, except in its impact on storage needs. As differences accumulate, internally to OmniPad it can become convenient to save a new difference base (for faster reconstruction, using fewer changes), but in our preferred embodiment the saved difference base does not automatically appear as a user-visible version.
To allow a powerful ‘Undo’ system (see below), the list-of-differences method is a strongly preferred embodiment, with a time-stamp on each stored difference.
The standard writing conventions of European-language text permit automatic segmentation into sentences. A sentence break is defined by a “.” followed by whitespace followed (if at all) by a capital letter. For this purpose a closing parenthesis or quotation mark must be allowed as the beginning of whitespace, and an opening one as the end of it. With the occurrence of a mathematical symbol at the beginning of a sentence, or of a trade name like “eBay”, an algorithm would require more linguistic sophistication to recognise the same sentences that a human does, but OmniPad can function without this exact agreement. (Linguistic tools that would always correctly identify sentences would also be capable of identifying clauses and other such substructures, leading to variations on the present invention that will be clear to those skilled in the art.) Whitespace and punctuation were largely absent in Roman writing, and in Asian scripts until more recently, but have now spread to most languages. Though many still eschew capitalisation, most have introduced reliable identifiers for sentence breaks. (In some cases, such as Korean writing, this process has included invasion by the separate sentence concept itself, changing accepted prose style.) We thus assume that a usually correct automatic segmentation into sentences is performed by a function within OmniPad.
Ancient Greek manuscripts separated units of text by a horizontal line called a paragraphos (“with/beyond the writing [graphos]”), which gives us the next size unit. This too has invaded many languages. Visual conventions to mark it usually include a new line, often an indent or an outdent, and sometimes extra vertical space. Every digital text file format includes a paragraph-break convention: for example, LATEX marks them by two successive ‘new line’ characters in the source file (treating single ones as whitespace); MSWord uses a single one, with visible line breaks created dynamically; HTML uses “<p>” to begin a paragraph, and optionally “</p>” to end one. The use of such conventions must be implemented within OmniPad format by format, but the net result is a well defined separation into paragraphs. A paragraph break invariably implies a sentence break.
Above this level, the only clear agreement is that the hierarchy should have a strict tree structure, with no multiple descent. A sentence cannot lie across a paragraph break, a paragraph cannot continue into a new section, a section is within one chapter, which lies in one book, and so on. The actual hierarchy varies between formats (for instance in the depth of section/subsection/subsubsection/ . . . allowed), so that to get the benefit of OmniPad features which refer to hierarchy a group of co-authors must agree on one file format, or on a set of formats whose hierarchy systems are mutually translatable.
We first discuss the nature of differences between parts of a single file containing text, then between a pair of such, and then those among a group. In each case, one file B is chosen as comparison base: for a single file, only one choice is possible. Single file
At the separation shown in the window 300, such a repetition is easy to spot, but still harder than a spelling or syntax flaw, as neither paragraph is defective in itself. Reading the text a second time, the undue familiarity of 321 is easily attributed to the previous read-throughs, rather than to the recent sight of 320, so the echo persists. (An echo can be effective prose, but may often give the reader a sense of moving backward, to an earlier point in the writers' case. It should never be unintentional.) As each persists through successive versions, it can accumulate cross-references, “as we said in Para m” or “as discussed on page n”, that unravel if it is removed, and must be detected and changed. It is far better to detect the problem early, before such intricacies build up.
A mismatch is a permutation if it substantially matches after interchanging of two neighbouring substrings, such as in the change between “The brown quick fox” and “The quick brown fox”, even if there is also a mismatch of whitespace sizes. (Whitespace is often messy after cut and paste.) A permutation may be of longer strings, for example rephrasing the previous sentence as [A mismatch is a permutation if it substantially matches after interchanging of two neighbouring substrings, even if there is also a mismatch of whitespace sizes, such as in the change between “The brown quick fox” and “The quick brown fox”.]. It may permute whole paragraphs, sections, or other recognised units. If the permuted substrings substantially exist in the descent of B, but do not exist in the descent of V, the mismatch is a relic permutation; otherwise, it is a new permutation.
If a string is moved to a distant location, one could formally treat this as permuting it with the intervening material, but it is more natural to the user to say “this has moved” and highlight it than to say “these have moved” and highlight both. In our preferred embodiment, currently defining “distant” as “more than three times the string's own length”, we therefore call this a transposition of the string. If the move substantially exists in the descent of B, but does not exist in the descent of V, the mismatch is a relic transposition; otherwise, it is a new transposition.
A rewrite is a mismatch which cannot be expressed in terms of gapped matches, transpositions or transposition steps up to a pre-set density. For example, “the quick red fox” could be obtained from “the quick brown fox” by deleting “brown” and inserting “red”, but this is too many steps for one word. Similarly, there are too many such steps in going from the sentence used above to [We call a mismatch a permutation if one string matches the other after swapping two neighbouring substrings, perhaps with a mismatch of whitespace sizes, such as in “The brown quick fox” versus “The quick brown fox”]. A break-down into such steps would produce an unreadable display. For comfortable display, our preferred embodiment sets the allowed density to zero: “brown” versus “red” in matching positions are then displayed in the same style as “plotoprasm” versus “protoplasm”. If the rewrite substantially exists in the descent of B, but does not exist in the descent of V, the mismatch is a relic rewrite; otherwise, it is a new rewrite.
Observe that a permutation or a transposition can contain other differences, such as if we permuted the above two paragraphs while deleting “A break-down into such steps would produce an unreadable display” and changing “we therefore call this a transposition of the string” to “we designate this therefore a transposition of the string.” With too high a level of such differences, however, and without the cue of corresponding position, the matching algorithms will not identify a permutation or a transposition. The result will usually be classified as a rewrite, or a gapped match. Multiple files Suppose there are several files V1, V2, . . . beside the reference base. If an identified difference occurs between B and just one of these files, it is a singular difference. If it occurs between B and more than one of them, as in the “growths misalignments” example above, it is an equal difference. If a string in B is matched (but imperfectly so) to imperfectly matched strings in distinct files Vi and Vj, these are conflicting differences.
These characterisations are important in the presentation of differences, addressing in particular problems (b) and (c) listed in the Background of the Invention above.
A single realisation of OmniPad on a particular machine may in the same manner store multiple WIPs, for different users or the same users, and handle each WIP as here described. No modification of the description below is required, except to set up a process by which a user gains access to the WIP or WIPs for which that user has authorisation, so as to begin work in a chosen WIP. The manner of setting up such a process is well known to those skilled in the art, with the most common being that the user presents a user identity and password. Several alternatives are listed in USPTO filing 60/891,534 “A Method and System for Invitational Recruitment to a Web Site” by the same inventors, hereby incorporated by reference. OmniPad may be operated in at least two modes. Moderated mode gives one identified user certain privileges of final decision. In consensus mode, no individual has overall authority. (Elaborations within the spirit of the present invention whereby one individual has moderator privileges over one section of the document, while another moderates a different section, will be clear to those skilled in the art.)
It is convenient here to introduce some definitions: those applicable to moderated mode, to consensus mode, or to both are marked M, C or MC respectively.
WIP (MC): A Work in Progress, as described above.
Work Group (MC): The set of users who currently have access to a particular WIP.
Document (MC): A WIP contains one or optionally more sections handled as separate document files. Each is given a label that persists through versions: OmniPad treats the document name as an editable aspect of the document, directly comparing to recognise identity of two documents (which thus share a label). Labels propagate, so that if B has enough points of resemblance to A to be classified as a version of A, while C has enough points of resemblance to B to be classified as a version of B, then A and C receive the same label. However, an embodiment may force the creation of a copy with a new label, if for example the users need to create a version rewritten for the South Asian market, without superseding the original for use in North America.
ID (MC): A tag on a document version file that may include the document label, a ‘last-modified’ date and time, the name of the co-author who saved it, in preferred embodiments the name of the WIP it belongs to, and whether it is a moderated mode ‘draft’ (see below).
Modification (MC): OmniPad defines modification separately from the operating system time-stamp (Windows, for example, includes moving an unopened file from one folder to another as ‘modification’, and updates its stamp). Provisionally, a file is marked as modified when it is saved, but OmniPad checks whether differences from a previous version actually exist; if none do, the time-stamp for that version is used. When a collection of documents created outside OmniPad is imported into it as a WIP, if they have pre-existing time-stamps accessible to the import process these are adopted as OmniPad time-stamps. If not, they are all stamped by the time of the collective act that imported them, to avoid spurious distinctions as to which is newer.
Moderator (M): A person in charge of a WIP. There is one moderator per WIP in moderated mode, none in consensus mode.
Co-author (MC): Collaborator on the WIP. There can be multiple co-authors on one WIP. A moderator also functions as a co-author.
Draft (M): A document version sent from the moderator to one, to several or to all co-authors. A draft is given an ID that includes the document label, a ‘last-modified’ date and time, the name of the co-author who saved it, in preferred embodiments the name of the WIP it belongs to, and the fact that it is a moderated mode ‘draft’. In the descent tree, described above, it is automatically given direct descent from all leaves extant at the time of issue, irrespective of internal evidence. The Moderator is assumed to have had all of them open. It thus becomes, temporarily or finally, the sole leaf on the descent tree.
Descent tree (MC): The directed graph whose nodes represent versions and whose edges represent the relation of direct descent.
Recipient list (M): The list of co-authors to whom a draft is sent.
To issue (M): for the Moderator, to send a draft to a co-author, with a version number. By default, when the Moderator issues a draft to any co-author, the Moderator is also on the recipient list. When the Moderator ends a session, or closes a document, by default any changed document is issued as a draft to the Moderator herself. The interface may provide a dialogue at this point by which the Moderator decides whether to add others to the list.
Proposal (M): A new version of a document in the WIP that a co-author passes to the moderator, preferably by saving within OmniPad or via upload to OmniPad, but email, carried CDs, etc, may be allowed, with digital form strongly preferred. (If it is not uploaded to OmniPad, the Moderator must enter it locally. If it is in hard copy, the Moderator must have it typed in. The not-via-OmniPad version is for Moderators with technically confused co-authors, and with time to compensate for them. The Moderator sets policy on these options.) A proposal always receives an ID.
Variant (C): A new version of a document in the WIP that a co-author uploads to OmniPad. A variant always receives an ID.
Moderator's board (M): The ‘light table’ or ‘cutting room’. The interface where the Moderator works and assesses the proposal and accepts or rejects changes. This contains a copy (with a new ID) of the most recent issued draft, and copies of any proposals received since that draft was issued.
Proposal response (M): When a proposal has been worked through in the Moderator's board, a proposal response is sent to the co-author behind the proposal. This log shows which part of the proposal has been adopted and what has not, and any comments by the Moderator on her choices.
Open (MC): A copy of a document is open (or fully open, when the distinction from ‘read-open’ below must be emphasised) to a particular user if that user can make changes in it without a new numbered version becoming visible to other users. This status can persist over separate log-in sessions, but the administrator may set an ‘idle time’ limit. If a copy of a document is open to a user who does not make changes for a time exceeding that limit, the document is closed and a numbered version issued. In moderated mode, this numbered version is treated as a proposal.
Read-open (MC): A version of a document is read-open if its contents are so displayed (in whole or in part) as to allow a user to transfer material from it. A version saved with an ID is not available for change: any future access made using that ID will produce the same content. A user can make a copy fully open, but any version saved from this copy will automatically have a new ID.
Working copy (MC): A version currently open, in which a user is making changes by new typing or by transfer of material from a read-open source. A user may select any version as working copy. In moderated mode the default selection is the most recent draft, unless that user has already created from that draft a newer version, which becomes the default. In consensus mode it is the most recent version created by that user, if any; otherwise, it is the most recent version created by any user.
Changes (MC): When a draft is compared to one or several subsequent proposals there will be differences in the text. These differences are referred to as changes.
Selector Widget (M): The widget used by a co-author in selecting which changes in one or more proposals, and what part of such changes, she wants to adopt.
Adoption (M): When the Moderator uses the Selector Widget to transfer a change from a proposal to the Moderator's working copy.
Assent (MC): When a work group member uses the Selector Widget to transfer a difference from an alternate version to that member's working copy. This includes Adoption, in the case where a moderator exists and is the user.
In either mode, a user acting as administrator sets up a WIP, and identifies other users with access, either by specifying identities from a larger pool such as the employee list of an organisation, or by giving the email addresses of these users, or by such other means as will be evident to one skilled in the art. Each such user is notified (in our preferred embodiment automatically notified), and provided with permissions and passwords as necessary. He or she must be registered with the server that runs the system: our preferred embodiment can pass a WIP invitation to the user by either a ‘to members’ pathway, or (following the method disclosed in the UPTO application 60/891,534 “A Method and System for Invitational Recruitment to a Web Site” by the same inventors, referred to above) by e-mail that includes a link to a page which explains how the user has been pre-registered, using the e-mail address as a unique ID, and provides access to the WIP. The user contributes a password to this process, but otherwise needs only to input a few mouse clicks. “User” may also include a collective identity for a set of people (such as a pool of technical writers or legal specialists) who provide input on a who-is-available basis. “User” may also include a software element such as a checker of spelling or style, by preference with a significant natural-language-analysis component. (A checker of “Is this word in the list?” as in MSWord would accept “we are lead to believe”: A more sophisticated program would recognize that “lead” is not here a licit verb form.) Such tools are imperfect as yet, but steadily improving: it is thus better to provide a plug-in slot and a secondary market than to build a checking system rigidly into an office system. By allowing software to be a user in the present system, we achieve this even where some users continue attached to hegemonic software.
In moderated mode, the administrator assigns a Moderator (who by default may be the same user as the administrator). The Moderator sets policy, such as the paths by which proposals may be submitted, and the proposed time between drafts. To allow for periods of unavailability or for other problems, in our preferred embodiment the system may allow changes of Moderator, by action of the administrator, the current Moderator, or agreement of a pre-defined quorum of the work group members. The Moderator may begin the co-authoring process by issuing a first draft: if not, the formal first draft is an empty document.
In either mode, a user logs in to the system, connects to the particular WIP (if this user is involved in only one current WIP, this step is preferably automatic) and sees a Working List of versions for consideration. (The list may be empty, if this user is the first to contribute.) By default, the list shown is of the current leaves of the tree. The list of all versions, however, may be called up and displayed in various ways, possibly including but not limited to sorting by time, by author, by amount of new material, by amount of new material accepted/rejected in later versions, or as 2D or 3D display of the descent tree, according to the choices of the implementer and user feedback. Any one or more of the earlier versions in the expanded can be selected (for example, but not necessarily, by a double click) to add to the Working List. In our preferred embodiment this remains true in moderated mode: optionally the Moderator may be empowered to refuse such access to versions earlier than the most recent draft, and hope that suggestions refused in it will thus remain dead, but users can often resurrect zombie versions from their own files. Group harmony will not be enhanced by their finding a need to do so. In particular, a standard option can be to include by default the most recent version created by the user, even if it predates the current draft. Comparison with the present draft then enables a My Changes display, which identifies those elements new to that version and shows which of them have been adopted in the current draft or Working Copy, and which not, together with any comments entered in adopting or rejecting them by co-authors or the Moderator. This solves the problem (e) in the Background to the Invention, as modifications refused by the Moderator or by other co-authors in reaching the file used below as Working copy will then automatically appear as differences with that version. These differences may be assembled into a User Change Log, which shows the full history of the adoption or rejection of changes proposed by the current user, together with comments, and draws attention to repetitions or near-repetitions by the user of changes which are consistently rejected. The user enters editing mode, and the system displays the content of the Working List versions, with their differences. This may be done in several ways, depending on available resources such as display space.
Multi-window view If a user's display can show four or more standard pages with enough pixels per letter for clear reading, and the physical size of these letters permits easy reading for that user with suitable vision correction as necessary, it may be convenient to display (
The direction of the arrow 715 shows the gap 710 to be a deletion, with the string 711 in its descent, while the direction of the arrow 735 shows the identical gap 730 to be a relic, distinguished as above via use of the descent tree. (There is an important difference between a sentence that a collaborator has not yet seen, and one that she has actively deleted.) Left-clicking on either arrow 715 or 735 would result in assent to that deletion or absence, the removal of the string 711 from the Working Copy, and either disappearance or ‘ghosting’ of the arrows 715 and 735. (A ‘ghosted’ item keeps its shape and color, but is highly translucent.) Right-clicking on either rejects both, resulting in the retention of the string 711 in the Working Copy, and either disappearance or ‘ghosting’ of the arrows 715 and 735. These click conventions, like those below, may be reversed, changed to single and double clicks, replaced by key presses, or otherwise replaced by interactions known to those skilled in the art, within the spirit of the invention.
Conversely arrow 725 shows the string 727 to be an insertion, with the empty string 720 in the descent of version 702, while version 700 does not have the string 727 (or a near match to it) in its own. Left-clicking on this arrow 725 accepts the insertion, resulting in addition of the string 727 to the Working copy 700, and in disappearance or ‘ghosting’ of the arrow 715. Right-clicking on this arrow 725 rejects the insertion, resulting in no change to the Working copy 700, and in disappearance or ‘ghosting’ of the arrow 715. If the mismatch were a relic, the arrow would be reversed.
The arrow 745 shows a rewrite, where some co-author in the descent of 704 has replaced a match or match for the string 740 with the string 747. (If the replacement was in the other order, the arrow would be in the reverse direction.) Left-clicking on this arrow 745 accepts the difference, resulting in replacement of the string 740 in the Working copy 700 by the string 747, and in disappearance or ‘ghosting’ of the arrow 745. Right-clicking on the arrow 745 rejects it, with no change in the Working copy 700, and either disappearance or ‘ghosting’ of the arrow 745.
The arrow 755 shows a rewrite in version 705 of the string 750 “ssssssss” as 757 “ssssss”, which is not in the descent of the Working Copy 700. This proactive change is likely—given competent collaborators—to be a valid difference, and acceptable to the current user. The reverse arrow would indicate that a change from “ssssss” to “ssssssss” is in the descent of the Working Copy 700, and suggest that the version 705 simply lacks it because its descent does not include the version that made the correction: however, it is possible that a version in the descent of the version 705 actively rejected it, and the current user might agree with this, or might spontaneously reject the correction as invalid. We therefore do not automate the choice, which would save user time at the expense of user autonomy, but we do provide the arrow directions as cues to history. Left-clicking on the arrow 755 accepts the rewrite, resulting in addition of the string 727 to the Working Copy 700, and either disappearance or ‘ghosting’ of the arrow 715. Right-clicking the arrow 755 rejects the rewrite, with no change in the Working Copy 700, and either disappearance or ‘ghosting’ of the arrow 755.
The multi-page display has its advantages, such as that one can compare the readability of versions in a direct read-though, but its limitations are evident.
Similar graphical means can display permutations and transpositions, but it is more convenient to describe them in the context of the USPTO filing 60/869,733 “A Method and System for Facilitating the Examination of Documents” by the same inventors, incorporated above by reference. The compressed view there disclosed simplifies both viewing and rearrangement of text. In summary, in the said method the user is enabled to move smoothly between viewing an entire document in a word by word display, through views that display only elements of increasing landmark value, to an overview of the document in a single display window. A document is parsed into a hierarchy, of which each node at every level (from chapter to sentence, clause or long word) has a display state (invisible, tokenized or open) for the way it is shown as part of an expandable view of the document. The contents opted for display within a tokenized view may be prioritized according to a system of landmark values. The view is modified by user input using an explicit data structure of nodes and states within the device controlling the display, or by structuring in another system the underlying logic of the arrangement of code that is acted upon by a web browser. The section hierarchy may be explicitly coded in the document format, or reconstructed from typographical evidence.
The results are illustrated in the two views in
The >-> arrow 920 indicates in this exemplary drawing that something within the element 921 has moved to the element 922; expanding element 921 by the chosen user-input scheme would result in a matching expansion of the element 922. If the expansion still shows only a subsection containing a moved element, a new >-> arrow will show the subsection of the element 922 to which it has moved: this requires that the said subsection be shown, in tokenized form, and hence that the elements containing it be open. This occurs automatically, by the rules embodied in the system, rather than by the user having to modify both views. Alternatively, the user could expand the display of element 922. The display of element 921 would expand accordingly, to show the context from whence the addition came. (The gap 960, however, might be the user's object of interest, so an expandable link to the element 921 from which it was taken—and moved according to the arrow 920 to somewhere in the element 922—may optionally be shown.) Expand to the level where individual sentences are open, and the specific moved text comes into view. In the case of Subsection 941, just such a matched expansion has taken place. The left panel 910 thus shows the text 941 which by the arrow 940 has moved to become the text 942, in a different § section expanded 943 sufficiently to show the text 942 in context and conform to the rule that the parent of an open or tokenized node is always open. The hierarchical context makes clear that the parent 931 of the text 941 has not merely moved to, but been rewritten as, the text 932. This is indicated to the user by a x-> arrow in this exemplary drawing: alternate arrow stylings will be evident to those skilled in the art, within the spirit of the present invention. Within the text 941 there is a gap 951 which is matched to the inserted text 952, as indicated to the user by the arrow 850, analogously to the insertion arrow 735 from the gap 730 to the highlighted string 711. As in that case, our preferred embodiment uses highlighting means characteristic of a computer display (such as color or blinking) rather than hard copy emphasis methods such as bold face, which may be present in the text and should not be confused with software highlights.
Single-page view: single file We begin discussion of the single view with the case of presenting a repetition, discussed above under single-file comparison. We first describe the uncompressed-display version.
The normal user choice, faced with such repetition, is to fix in which context the repeated item should remain. It is thus appropriate to display some text around each. If two or more repeated strings are far enough separated that this cannot be done in the manner of
Our preferred embodiment, however, and one that becomes far more necessary if the repeated units are longer, is to use the variable compression introduced in
Another single-user aspect of the present invention is that of structured Undo. The incremental change storage in our preferred embodiment lets OmniPad back-track through changes in a document, section, paragraph or other defined part, re-creating something that the user interface can treat as a comparison document, in precisely the framework used for any other, importing differences on any scale. (Thus, for example, “undo the changes in this paragraph” becomes effectively “import the earlier version of this paragraph” in a unified interface; or parts of it, or individual differences, can be imported. The fact that some of these changes were made before a correction in another paragraph, and some after, does not complicate the user's experience.) The user need merely define the active part, by selection mechanisms that will be familiar to one skilled in the art, set the previous version used for comparison (by default the version that was loaded to create the current Working Copy, but allowing selection of an earlier version from the descent tree or by a widget such as a slider controlling the reference time, or by other means evident to one skilled in the art). The user then proceeds to use the Undo feature, which may use an option permitting the user to undo all the changes in the active part with a single command, or a display showing the changes in the selected region of text, which the reader may read through and accept or undo individual changes, or step back through the changes in reverse temporal order. In the latter case, optionally the user may choose to let a change remain, but without (as in standard Undo) losing access to changes that occurred earlier. The selected region is redefined to exclude the text containing the change permitted to remain, and the sequential Undo proceeds as before.
“Undo” is traditionally a single-file function, and can be handled in a single-window view, making it appropriate to list here. However, its logic and interface are better appreciated as comparison and interaction with an earlier self of selves of the current file, and can also be handled by the multiple-window approach above, and with the variable compression illustrated in
Single-window view: multiple files We now address the presentation in a single window of differences between a file and one or more of its neighbours. What follows is an exemplary single-window embodiment of the editing and merging use of dynamically matched texts, not to be construed in a limiting sense; many other interaction schemes can be developed within the spirit of the present invention.
An embodiment within the spirit of the present edition could follow a classical “variorum edition” layout, with all alternative forms and spellings side by side, or in columns, with attribution. This is helpful to scholars, handles well the fact that Hamlet's script may have said “Oh that this too, too sullied flesh should melt” (though not that he might have pronounced it to suggest “solid” also), and is well supported by fixed print. It is cluttered, however, and poorly suited to describing rearrangements of the text. A multi-threaded narrative like Orlando Furioso could transpose dozens of pages without disturbing the logic, and the creator could well make such a change for impact. Most 19th Century novels were more fixed in their sequence, many 21st Century business documents are less so. (Do you put the Marketing section before Technology? This can change with the intended readers.)
We describe first the presentation of small scale changes, that (like the repetition in
In our currently-preferred embodiment of a single-window interface,
In each case the tab 1521, 1522 or 1523 is greyed to show that its ‘contents’ (differences they draw attention to) are already on display. When a source button is clicked, each tab related to the corresponding file has its contents displayed, including those only visible when the window is scrolled. Window 1501 shows the transposition 1531 proposed by Anne, together with her deletion 1535. (In editors following the current state of the art, the change 1535 would be lost for display purposes under the under the movement, displayed as deletion and insertion. Window 1532 shows in-line, and highlights, the small insertion 1532 proposed by George. The sub-window 1533 in window 1503 shows as a slip (boxed passage of text) the revision proposed by Marion. Double-clicking any one of these changes accepts it, and the text adjusts to show the result, without highlighting it unless another reason exists to do so. Clicking the tab itself rejects it, and the highlighted change display disappears. In either case, the tabs remain for later reference.
In
Had Marion's change been a brief one like George's, normally displayed within a line, it would follow 1731 and be marked in-line there. If the match of Anne's and Marion's revision of the two sentences moved by Anne meets the normal criteria for in-line display, Marion's version is displayed in line, rather than in a slip 1733.
Where multiple versions of a short stretch of text exist, our preferred embodiment allows the user to switch to a display like
Double-clicking the proposed change 1733 gives the situation of
In general the highlighting of changes in tabs is color-coded, using saturated colors for relic mismatches, dramatic unsaturated ones for those representing novelty. (Other ways of representing this distinction, within the spirit of this invention, will be evident to any person skilled in the art.) Our preferred embodiment contains a default set of colors, constructed in consultation with persons skilled in the lore of human color perception and its variations, but is customisable either color by color or through selection of an alternate pre-constructed set.
Where describing a single difference does not fit within a single, contiguous page display at comfortable resolution, our preferred embodiment again uses variable compression.
Local changes such as rewrites, insertions and deletions clearly fit equally well into this display scheme. Where text is displayed in the fully open state, the mechanisms described for the uncompressed version apply without change. Where it is not, the invention simply applies the tabs and other change markers to the compressed version. To see that a paragraph or section has moved, and from where to where it has moved, the user chooses a high-level overview display. To see how it has changed while moving, the user moves in for a closer view. This solves problem (c) listed in the Background to the Invention.
The present invention supports this workflow, but it is not the most usual among collaborators. Commonly each author makes a new version and sends it (often by email) to everybody. To avoid re-inventing the wheel, another author who has not yet started on this round's editing—and is stirred into action by receiving another's copy—takes the new version into account, even using this and not the official draft as an editing basis. If there are two already, take account of them, and so on. It easily happens that the flow of
Rather than try to enforce the flow in
Another author such as Marion, working on the document after this version has been saved into OmniPad by George, will see the comment and reply 2412. If there has in the meanwhile been a response also from Godot, the dialogue will be folded together in temporal order. (Optionally, if a complex discussion develops, it may be preferred to move it into a more separated display with descent tracking.) Marion is free to add to or delete the dialogue. If a user deletes a comment, with or without additions by other users, it disappears from her view of all later versions unless and until a reply is added which she has not seen. In the latter case, the dialogue reappears as a whole, with the earliest entry after her deletion displayed in focus position, with earlier and later entries above and below it or available by scrolling.
Our preferred embodiment of the present invention is in the form of ‘software as a service’ (SaaS), delivered by means of the web, though many local embodiments will be evident to one skilled in the art, within the spirit of the invention.
In this embodiment, copies of the versions discussed above are kept on a server maintained by the service provider; an author can
When a user first connects to an OmniPad web site, she establishes a means of continuing access to the site and to a space she controls, to files within it, and in some cases to files within the space controlled by other users. In our preferred embodiment, each WIP exists in the space of its creator under (i). This may be by the process of registering an OmniPad identity and agreeing a password with the site, as is now standard in many web sites (with variants such as whether a user-created password is typed in, or a server-created one is emailed to the user's address). If the user initiates the contact, this will be the normal process, perhaps involving the payment of a subscription fee, perhaps gaining access to an introductory level of free service. If the user is responding to an invitation from an existing member, this process may optionally be abbreviated by use of the email ID to which the invitation was sent as a default OmniPad identity, and use of emailed single-use links as an alternative (once or repeatedly) to a password. These options are discussed in more detail in the USPTO application 60/891,534 “A Method and System for Invitational Recruitment to a Web Site” by the same inventors, referred to above. It suffices here to assume that each member of the site has access to it, and in particular that each member of the work group associated with a particular WIP has access to that WIP, whether it be in that member's space or another's.
It is a primary purpose of the present invention to make this easily apparent, even to a user who does not open a file in an OmniPad editing environment (as disclosed above in a plurality of embodiments). In contrast to
A window 2600 appears within a browser, or (as discussed later) as an apparent window of the operating system (Windows, MacOS, etc.). Within this is a subwindow 2601 for the contents of the WIP, which in this illustration contains successive versions of a single document, rather than of a connected set of documents. (Extensions necessitated by the latter case will be evident to one skilled in the art.) The overall WIP title 2610 need not be repeated in the display of the individual files, so—irrespective of the filenames under which they are stored in the server—they are identified by uploading author and by date. (A consistent system of version numbers could be automatically generated, but for our preferred embodiment we consider this unnecessary.) The marker ⊕ indicates the presence of supplementary material such as graphic files in PostScript (“.eps”) or image formats, compiled versions such as Portable Graphics Format (“.pdf”), text explanations—too big for comments—of why the uploading author made certain changes, or text suggestions of what other authors should do next, test code that implements an algorithm discussed in the document, or any other associated matter the author chose to upload in the same session. (On gaining access within a set number of hours, such as 12, after an upload, the user may be asked by a dialogue box “Continue session?” so that a web interruption need not mar this relationship.) Clicking the ⊕ icon opens or switches to a window showing the associated material. The column 2640 shows the file types present at a particular point in a similar history to the one that produced
Double clicking a version opens an additional window, optionally in a new browser tab, in which a compressed version of the kind illustrated in
Timothy may click on the button 2650, in which case these three versions are the default set brought into the OmniPad editor, including all the slips, tabs and other apparatus discussed above. If he has selected any versions in the gray area 2630 they will be included.
In the case of the alternative version 2699 of the window 2600, the default is to deal with only the most recent upload 2698, and consider its changes from his own latest version 2695 as Working Copy, as shown by the inclusion of everything else in the gray ‘dealt with’ area 2631. This relies on Etienne's judgement with respect to inclusion, omission or modification of Ankur's changes in upload 2697. However, if Timothy wishes to include upload 2697 directly, he can click to select before clicking the edit button 2680 for this case. Alternatively, he may choose to click his own previous upload 2695 to deselect it, and work only from Etienne's version 2699 with a fresh eye. The editing proceeds as discussed in the pages above, and the final Save of a session is considered an upload for purposes of generating the descent tree as used in the display in
Alternatively, Timothy may choose to work with the files on a local computer. Since image files are often large, if the successive versions all directly contain them the time for upload and download may become unnecessarily large. If they are stored separately as supplementary files, with access via the ⊕ buttons shown in
In our preferred embodiment, which may be implemented for use with many browsers and operating systems by using the Web-based Distributed Authoring and Versioning (WebDAV) mechanism, a folder appearing on a web page can appear and act very similarly to an OS folder on the user's desktop. In particular, items can be dragged from the OmniPad window shown in
Other mechanisms beside WebDAV can be used for this purpose, but they share its characteristic that the user must go though some OS-level steps of establishing the necessary connection. A user prepared to do this (and able to follow the instructions involved) will often be equally prepared to install a ‘thin client’ on the local machine, overriding malware warnings about executable files downloaded from the web, which permits the appearance of the window in
To maintain the distinction between the main version files and supplementary material, the user is able to drop files not into the window 2601 as a whole, but into one of the ‘entry ports’ 2660 or 2661, as appropriate.
Where WebDAV, remote mounting, etc., are blocked by protective firewalls or plain confusion installed by the technical staff of the user's institution, or the user resists setting up a remote transfer system of this type, clicking the button 2651 or 2653 opens the standard ‘browse the file hierarchy’ dialogue box of the OS by which the user can select a file to upload, or a folder into which to download a selected file. In our preferred embodiment the user is able to select transfer multiple files for which upload or download is simultaneously commanded by the ‘OK’, ‘Open’ or similar click, rather than repeat the dialogue and ‘OK’ for each file.
The button 2652 does something more than manage user choices in file transfer. The currently selected files in the window 2601 are assembled into a single file of a type determined by the user's current settings, which shows the best approximation to the change information displayed by OmniPad (opening with that set of files) that can be read and used with the editor preferred by the user. This may be a locally installed version of OmniPad, in which case the match will be close (subject to differences between the version on the web and one downloaded and not recently updated), or a default editor associated with the file type, or another editor specified in the user's preference settings. All settings may be reached, and modified by a standard dialogue box with explanatory text and options to click, via the button 2656.
The button 2655 leads to a dialogue by which the user may invite collaborators (identified by email addresses or by member IDs specific to the particular OmniPad site) to join the group working on a WIP; its use may be restricted to the Moderator of the WIP, if any. An invitee who is not already a member of the site may, in accepting the invitation, be required to go through a registration process and (depending on the embodiment and the work style chosen for the group) to mount connections or install a thin client for one of the file transfer mechanisms above. Alternatively, access may be arranged as disclosed in USPTO filing 60/891,534 “A Method and System for Invitational Recruitment to a Web Site” by the same inventors, referred to above.
A member of an OmniPad web site has a home page on that site. A button on that page leads to a dialogue (not shown, being evident to any person skilled in the art) by which the member can create a new WIP, set whether it is Moderated, name a Moderator (by default the creator of the WIP, but not by definition), issue invitations to a initial collaborator list, pay any necessary fees, and so forth.
As well as the descent tree display in
At the beginning of a joint writing project, at least one user is assumed in
After either pathway 2710 or 2711, the system intializes 2720 the data structure of the descent tree. For a single file this is trivial; if multiple files have already been created or uploaded, their descent must be decided in the manner described in detail above.
The user then causes the system to send 2725 information of the project's creation to other proposed authors, identified either by IDs within the embodiment of the present invention or by email addresses, and giving them an address by which they can access the folder created in step 2701. The system creates IDs as necessary for these invited collaborators, and records permission data for them to access the said folder.
The next step 2730 is user-driven, in that a particular user in the group of those with access privileges connects to the embodiment. In step 2730, the system verifies the user password or other means of authentication, and permits this user to open 2733 the folder displaying the project.
The opening display then 2735 shows the descent tree, in the manner of
In case 2740 the system opens a single or multiple window display over the web for the user, showing the file or files opened in an integrated manner that permits editing and harmonizing as discussed (in particular) with reference to
In case 2741 the user downloads either the selected set of versions as distinct files, or an integrated version created by the embodiment to be conveniently edited in a particular application or set of applications. Such an application may include a local embodiment of the present invention, using the structure of the integrated version to enable use of the tools specifically described above in relation to it, or may be word processing software existing independently of the present invention, in which case the presentation of variants, additions, deletions, etc., must be adapted to what is supported within that software. This pathway concludes with the uploading of a revision, which is stored as a new and separate version, without overwriting earlier versions.
When a new version has been saved by a user following pathway 2740 or 2741, the embodiment updates the descent tree, by string comparison as described above. This process may be optimized by various means evident to one skilled in the art, such as to record and associate with each version those substrings already identified as originating in that version. Search in the new file for the presence of the particular strings thus associated with leaves of the tree may provide all the direct descent information that a particular embodiment requires. Detailed comparison of the new version with at least each of the descent tree's leaves remains necessary for the editing process, if this version is chosen as working copy in a subsequent round of editing.
When the descent tree has been updated, the embodiment tests it 2760 for the presence of more than one leaf. If more than one leaf exists 2762, it is necessary for at least one user to return at least once to the authentication step 2730 or (not shown) if already authenticated to the opening step 2733, and proceeding through the path 2740 or 2741 to the update step 2750. If only one leaf exists 2761, it may be a final version. By contact between the authors (using methods outside the embodiment, or a variety of possible means within it that will be evident to one skilled in the art), this question is decided 2770. If 2772 a new revision is necessary, one or another author agrees to perform it. Otherwise 2771, a final version has been reached 2780, and may be published, transmitted to an intended recipient, or otherwise dealt with according to the needs of the authors.
In an embodiment the step of determining the original version comprises the steps of: determining earliest occurrences of at least one substring; setting a file comprising the earliest unique substring as the original file.
In an embodiment the method discloses wherein a first re-occurrence of a unique substring in a file is used as evidence of direct descent from the file comprising the unique substring originally.
In an embodiment the invention relates to a method and system for facilitating the production of documents, comprising the steps of assembling multiple versions of a document or related group of documents on a computer; defining an extensible set of creators with access to the said document or group; attaching a creation date and time to each version file; attaching a creator's identity to each version file; comparing version files pairwise to find exact or partial matches of substrings; finding earliest occurrences of unique substrings; deriving a descent tree for the version files present; displaying the said descent tree to a user.
In an embodiment access to the said document or group is via an internet or extranet, and the said collaborators are granted access to the said group of version files, said access being denied to non-collaborators, and including the power to view or download existing files and the power to upload or by editing create and save new files.
In an embodiment access to the said document or group is via an internet or extranet, and a founding member of the set of creators invites others to the said set by a means that causes the server to grant them access, said access being denied to non-collaborators, and including the power to view or download existing files and the power to upload or by editing create and save new files.
Furthermore may a founding member of the said set of creators at any time invite another user to the said set by a means that causes the server to grant the said user access, said access being denied to non-collaborators, and including the power to view or download existing files and the power to upload or by editing create and save new files.
In addition, an embodiment of the invention discloses where any member of the said set of creators can at any time invite another user to the said set by a means that causes the server to grant the said user access, said access being denied to non-collaborators, and including the power to view or download existing files and the power to upload or by editing create and save new files.
In addition, an embodiment of the invention discloses where one member of the said set of creators is distinguished as the Moderator of the said group.
Furthermore, an embodiment of the invention discloses where the said creation date is a date of saving.
Furthermore, an embodiment of the invention discloses where the said creation date is a date of saving, said date being preserved when the said version file is moved or copied without internal changes.
Furthermore, an embodiment of the invention discloses where the said creation date is a date of file upload to a server.
Furthermore, an embodiment of the invention discloses where the said identity is the log-in identity, on a shared access computer, of the user saving the said version file.
Furthermore, an embodiment of the invention discloses where the said identity is an identity used for access to the server on which the method and system is embodied, by the user uploading the said version file.
Furthermore, an embodiment of the invention discloses where the said comparison uses the Smith-Waterman algorithm or a derivative thereof.
Furthermore, an embodiment of the invention discloses where the first re-occurrence of a unique substring is used as evidence of direct descent.
Furthermore, an embodiment of the invention discloses where the said tree is displayed as a tree diagram.
Furthermore, an embodiment of the invention discloses where the said tree is displayed as a sequential list with direct descent links.
Furthermore, an embodiment of the invention discloses where the leaves of said tree are visually distinguished, optionally together with most recent version file created by the said user.
Furthermore, an embodiment of the invention discloses where the leaves of said tree are operationally distinguished, optionally together with most recent version file created by the said user, as a set of files that can be downloaded by the user with a single click or command.
Furthermore, an embodiment of the invention discloses where the set of files to be downloaded can be modified by clicking on the icons or names or other representatives of a file that is to be added to or excluded from the set.
Furthermore, an embodiment of the invention discloses where the said comparison is also used between each version file and itself.
Furthermore, an embodiment of the invention discloses where the leaves of said tree define a default set of version files to be shown to the user in an integrated display, minimizing repeated display of identical material.
Furthermore, an embodiment of the invention discloses where the said set may additionally include a working copy selected among non-leaf nodes of said tree.
Furthermore, an embodiment of the invention discloses where the user may add or remove members of the said set by clicking on elements of the display 1(h).
Furthermore, an embodiment of the invention discloses where a repetition revealed by the said self-comparison is displayed to the user as a possible error.
Furthermore, an embodiment of the invention discloses where each locus of mismatch among version files in a subset currently considered, as revealed by the said comparison, is displayed by software on the server or downloaded to the user's computer to the user as a set of alternate versions, optionally with the identity of a creator attached.
Furthermore, an embodiment of the invention discloses where the display shows the alternate versions as distinct but possibly overlapping changes relative to a version file selected as working copy.
Furthermore, an embodiment of the invention discloses where the default working copy is the most recent version file previously created by the user to whom the display is presented.
Furthermore, an embodiment of the invention discloses where the default working copy is the oldest file in the group.
Furthermore, an embodiment of the invention discloses where the default working copy is the most recent version file issued as a draft by the group's Moderator.
Furthermore, an embodiment of the invention discloses where the differences between an author's most recent version and the first version created by the Moderator that takes account of that version are listed and sent to that author, with any comments by the Moderator on reasons for their acceptance, rejection or modification.
Furthermore, an embodiment of the invention discloses where the working copy is selected by the current user.
Furthermore, an embodiment of the invention discloses where the members of the said set of creators may include a program module with natural language processing capability.
Furthermore, an embodiment of the invention discloses where the set of version files considered is a pair of files, one of the said files being judged to be descended from the other said file.
Furthermore, an embodiment of the invention discloses where the display distinguishes between deletions, insertions, rewrites and transpositions.
Furthermore, an embodiment of the invention discloses where deletions, insertions and rewrites are displayed within a transposed section of text, separately from the fact of the said section being transposed.
Furthermore, an embodiment of the invention discloses where said differences are shown to the user by marks connecting separate windows in which distinct version files are displayed.
Furthermore, an embodiment of the invention discloses where said repetitions are shown to the user in a single window.
Furthermore, an embodiment of the invention discloses where said repetitions are shown to the user by marks connecting separate windows in which distinct parts of a version file are displayed.
Furthermore, an embodiment of the invention discloses where said mismatches are shown to the user by marks at or connecting points within a single window showing an integrated view of multiple version files.
Furthermore, an embodiment of the invention discloses where variable compression allows widely separated repetitions to appear in said single window.
Furthermore, an embodiment of the invention discloses where variable compression allows the source and target locations of a transposition to appear in said single window.
Furthermore, an embodiment of the invention discloses where the said variable compression is modifiable by user input.
Furthermore, an embodiment of the invention discloses where the said variable compression is modifiable by user input.
Furthermore, an embodiment of the invention discloses where small differences are shown as inline substitutions.
Furthermore, an embodiment of the invention discloses where large differences are shown as contrasting boxes of text.
Furthermore, an embodiment of the invention discloses where each creator may add a comment, separate from the text, at any point in the text.
Furthermore, an embodiment of the invention discloses, where a creator can add to another's comment, such that a later access will show the sequence of additions with attached identities of the commenters.
Furthermore, an embodiment of the invention discloses where the Moderator may at any time issue an official draft of a document in the work in progress which by fiat has descent from all previous version files of that document.
Furthermore, an embodiment of the invention discloses where each locus of mismatch among version files in a subset currently considered, as revealed by the said comparison, is indicated to the user by a marker, optionally with the identity of a creator attached, such that clicking the said marker causes a full display of the said mismatch.
Furthermore, an embodiment of the invention discloses where the user may select, among the creators whose versions are in the subset currently considered, those for whom the said mismatches with the said working copy are to be displayed in full.
Furthermore, an embodiment of the invention discloses where the user may delete a particular marker from display.
Furthermore, an embodiment of the invention discloses where the user may in a single step delete all the markers indicating changes due to a particular creator from display.
Furthermore, an embodiment of the invention discloses where the said default set of files may be integrated for user download as a single file in which differences are indicated within the format conventions of an editor external to the embodiment of the present invention.
Furthermore, an embodiment of the invention discloses where the said repetition is marked in a downloadable file within the format conventions of an editor external to the embodiment of the present invention.
Furthermore, an embodiment of the invention discloses where the said subset set of files may be integrated for user download as a single file usable with editing software embodying the present invention that has been installed on the user's machine.
Furthermore, an embodiment of the invention discloses where the said subset set of files may be integrated for user download as a single file in which differences are indicated within the format conventions of an editor external to the embodiment of the present invention.
Furthermore, an embodiment of the invention discloses where the said subset set of files may be integrated for user download as a single file in which differences from the said working copy are indicated within the format conventions of an editor external to the embodiment of the present invention
Furthermore, an embodiment of the invention discloses where the existence of supplementary material associated with any particular version in the tree is indicated by an iconic mark.
Furthermore, an embodiment of the invention discloses where the existence of supplementary material associated with any particular version in the tree is indicated by an iconic mark.
Furthermore, an embodiment of the invention discloses where clicking the said iconic mark opens a list of the said supplementary material.
Furthermore, an embodiment of the invention discloses where clicking the said iconic mark opens a list of the said supplementary material.
Furthermore, an embodiment of the invention discloses where displays to the user are in a browser window.
Furthermore, an embodiment of the invention discloses where said browser window resembles a folder in the user's OS.
Furthermore, an embodiment of the invention discloses where displays to the user are in a window on the user's desktop, independent of a browser.
Furthermore, an embodiment of the invention discloses where a user may download a version or set of versions from the said group by dragging their icons to the user's desktop or a selected folder.
Furthermore, an embodiment of the invention discloses where a user may add a version or a set of versions or supplementary material to the said group by dragging their icons from the user's desktop or a selected folder.
Furthermore, an embodiment of the invention discloses where the said Moderator may attach deadlines to the next revision expected from individual co-authors.
Furthermore, an embodiment of the invention discloses where the display is structured to make each collaborator's versions clearly visible as a subset.
Furthermore, an embodiment of the invention discloses where each subset displays the said collaborator's relation to a current deadline.
Furthermore, an embodiment of the invention discloses where differences between the working copy and the current user's latest previous version are displayed, with any comments associated with non-acceptance by co-authors or the Moderator.
Furthermore, an embodiment of the invention discloses where the adoptions or rejections specifically of changes proposed in the current user's previous version are distinctively displayed.
Furthermore, an embodiment of the invention discloses where the full history of the adoption or rejection of changes proposed in all the current user's previous versions are distinctively displayed.
Furthermore, an embodiment of the invention discloses where the user may accept, reject or modify displayed differences, retain detected repetitions or delete one or more of the repeated segments, and modify any element of the text.
Furthermore, an embodiment of the invention discloses where the user may select a segment of text and perform a reverse-temporal sequential “undo” addressing only changes within the said segment, relative to a selected or default earlier version.
Furthermore, an embodiment of the invention discloses where the user may omit an “undo” in the reverse-temporal sequence and still proceed to undo previous steps which did not modify the same or overlapping text as was modified by the change whose omission is omitted.
Furthermore, an embodiment of the invention discloses where the user may scan the said segment of text, examine the changes shown, and click to select those to be retained or (according to preference) those to be undone.
Furthermore, an embodiment of the invention discloses where the user may with a single click undo all the changes in the said segment of text.
In an embodiment of the invention a computer program product may disclose a method that further comprises the step of determining the original version by performing the steps of: determining earliest occurrences of at least one substring; setting a file comprising the earliest unique substring as the original file.
The foregoing has described the principles, preferred embodiments and modes of operation of the present invention. However, the invention should be regarded as illustrative rather than restrictive, and not as being limited to the particular embodiments discussed above. It should therefore be appreciated that variations may be made in those embodiments by those skilled in the art without departing from the scope of the present invention as defined by the following claims.
| Number | Date | Country | |
|---|---|---|---|
| 60884230 | Jan 2007 | US |
