Patent Application
20070088729
The present invention relates to the field of computer software, more particularly to managing or manipulating historical file changes.
U.S. Pat. No. 6,108,668: “Method and system for undoing edits within selected portion of electronic documents” filed Apr. 18, 1997 incorporated herein by reference, provides a method and system, to be utilized with an editing system having electronic document editing capabilities, which provides an ability to selectively undo previous edits performed upon a selected particular portion of an electronic document. The method and system provide the forgoing objects in the following manner. Previous edits performed within an electronic document are stored. A contiguous block of data within an electronic document wherein the stored previous edits are to be undone is selected. In response to user input, part or all of any of the stored previous edits that have been done within the selected contiguous block of data are then undone.
U.S. Pat. No. 6,111,575: “Graphical undo/redo manager and method” filed Sep. 24, 1998 incorporated herein by reference, a graphical undo/redo manager that provides a graphical indication of multiple tasks that were recently performed. A user may undo multiple tasks in one step by selecting a task the user wishes to revert to, and the graphical undo/redo manager then undoes all the commands that were done subsequent to the selected task, taking the computer program to a desired state in only one user operation. In similar fashion, a user may redo multiple tasks in one step by clicking on a selected subsequent task (that was previously undone) that the user wishes to go forward to, and the graphical undo/redo manager then redoes all the commands between the last undo and the selected task, including the selected task. In addition, the graphical undo/redo manager provides for collapsing multiple tasks into a marker, either automatically when certain commands are executed in the computer program or upon command by a user for future reference.
U.S. Pat. No. 6,185,591: “Text edit system with enhanced undo user interface” filed Jul. 29, 1997 incorporated herein by reference provides an edit system having an enhanced undo interface, that permits the selective display of undo elements intermixed in the edit view of the document with actual text elements and positioned relative to the affected text The user may select any undo element and selectively restore changes to the text. A series of user interface enhancements provide the user with a flexible set of capabilities for manipulating and assessing changes to a document.
While the ability to undo actions in a program has been known in the prior art as well as the ability to undo a series of actions in a program, no-one has offered users of a given program the ability to arbitrarily modify, rearrange, undo, and redo any action in the history of actions performed during the course of operating the program, much less the ability to do so across multiple use sessions of the program. Nor has anyone offered the ability to turn the same arbitrary series of actions into a script for that program. The ability to undo and redo actions is a powerful and oft-used tool in any reasonably designed application, but there is much more that could be done with a history of actions. Currently, programs offer the user the ability to undo and redo the n most recent actions in series of actions, but if n is exceeded, the action is forgotten, which can make life difficult for the user, if by some chance a mistake was made at the n+1st prior action or before. A solution embraced by some applications is to allow an “unlimited” number of undo operations, starting from the time a given file is opened or created, but only within the limits of a single use session. This extension is certainly an improvement, but it still does not solve all the problems of manipulating data in a program. Adobe Photoshop, for example, enable a fixed undo for a given editing session. In addition to this history, it also has a separate scripting or actions facility.
One situation where this solution is inadequate is the case where a file is received from another user of the program, and the receiver wants to discover how exactly the file was made—what was the process that resulted in the file's final state. To make this more concrete, consider the case of a 3d-manipulation tool. It becomes extremely difficult to guess and recreate a series of transformations that led to the creation of even a simple 3d object once the number of steps passes a relatively low threshold. The same is the case for image manipulation—a series of filters and selections is exceptionally difficult to reproduce even for experienced users of advanced image manipulation applications. Thus, not maintaining a complete and accurate history of transformations made on a given object results in loss of useful data that could be shared between users, or even simply between use sessions.
A method is needed to improving handling data history transformation of data records.
The goal of the History Manager is to give the user a completely modifiable history of a given data set from the creation of the data set to the current moment. This invention could be applied to individual data items (e.g., images) or a sequence of data items. To achieve this goal, the History Manager needs to offer the user a specific set of tools through a certain general interface, which in combination constitute the invention. Firstly, the History Manager would offer the user the ability to toggle arbitrary actions in the history—this differs dramatically from the simple ability to undo and redo the n most recent actions. Here, if the user wishes to remove the ith action, it is not necessary to remove all n−i+1 actions after it. The user can simply click a check box or some equivalent user interface item and have the effect of the action removed from the history, resulting in the re-computation of the output from the nearest prior active action through the most recent active action, including the effects of all active actions in between.
Secondly, the History Manager would permit the user to modify the attributes of any given action in the history, which would then result in the re-computation of all the active actions from that point forward through the current action. This feature is also dramatically different from other undo options in that a given command issued by the user can only be undone, not modified. Previously, if the user wants to see the results of changing a given attribute from an action early in the history on the output of all of the following actions, the user has to go back to the action initially made and remove it and all of the actions that follow it and recreate all of the work that was previously completed. With the History Manager, however, the user can simply change the attribute of the action without having to recreate any other work.
The next major use of the History Manager would be script creation. Currently, in many applications, if the user knows in advance that a script needs recording, it is possible to select a “Record Macro” option that will record some series of actions that could later be reused. However, such foresight is not always possible. It is much more convenient to simply do a series of actions, and after modifying the actions to achieve the desired result, simply click a button that turns selected actions into a script. Also, since this script is created directly from the history of actions, the individual steps can easily be modified graphically—simply deselect whatever actions are not needed, rearrange actions into the best order, and modify the action attributes before or after creating the script with the History Manager. In other words, the user can create a script from a discontinuous set of actions without knowing in advance that the script will be needed. In addition, the saved script could be edited by a user outside the context of the History Manager or its host application. The user could edit a text file (e.g. an XML file) to reorder the actions or otherwise modify the actions or the attributes.
Furthermore, the user may want to be able to annotate the complete history or individual actions in the history with metadata describing the step—perhaps with the rational as to why the step was taken. This feature may in particular be useful in the creation of tutorials. In essence, the tutorial creator could simply do all the steps required for the tutorial, and then go back and comment as to why a given step was necessary. At that point, the file itself would become the tutorial—a person who wants to know how to create a particular result would simply open the file and review the history and the metadata associated with the history and its individual actions. This feature is of particular interest because it can greatly aid new users in learning an application, which in turn increases the possibility that the application will be useful and successful.
It is therefore an object of the invention to manage data record actions by accumulating in a first action history record, a first sequence of actions performed on a first data record, selecting one or more first actions from the first action history record, and performing a manipulating operation on one or more of the first actions, the manipulating operation modifying the first sequence of actions to produce a second sequence of actions.
It is a further object of the invention to perform the second sequence of actions on the first data record to produce a second data record.
It is yet another object of the invention to create a second action history record associated with the second data record and save the second action history record or display the second data record.
It is yet another object of the invention create a marker in the first action history record, the marker comprising information for locating the second action history record and the second data record.
It is yet another object of the invention create an index record for locating the second data record and save index information in the first action history record.
It is yet another object of the invention to perform the modifying operation by performing any one of the further steps consisting of moving a first action from a sequential position of the first sequence of actions to a new sequential position of the first sequence of actions, inserting a second action into the first sequence of actions such that the third action comprises an action sequence preceding an action of the first sequence of actions, inserting a program module into the first sequence of actions, modifying the sequence of the first sequence of actions, undoing one or more of the first actions, redoing one or more of the first actions, or operating on one or more of the first actions. Furthermore, the operating step consisting of any one of enabling a first action, disabling a first action, adding a new action, deleting a first action, copying a first action, pasting a first action, changing the first action sequence, modifying parameters of a first action, or annotating an action.
It is yet another object of the invention wherein the modifying operation is performed responsive to a GUI event.
It is yet another object of the invention to select one or more actions of the group of first and second actions, generate a program module reproducing effective functionality of the selected one or more actions, and save the generated program module.
It is yet another object of the invention wherein the generated program module comprises a script.
It is yet another object of the invention to accumulate in the first action history record, the first sequence of actions performed on the first data record across sessions, the sessions comprising any one of a user session, a program session, a communications session or a computer session.
It is yet another object of the invention to, responsive to a GUI user action, perform an action of the first sequence of actions.
Additional features and advantages are realized through the techniques of the present invention. Other embodiments and aspects of the invention are described in detail herein and are considered a part of the claimed invention. For a better understanding of the invention with advantages and features, refer to the description and to the drawings.
The subject matter which is regarded as the invention is particularly pointed out and distinctly claimed in the claims at the conclusion of the specification. The foregoing and other objects, features, and advantages of the invention are apparent from the following detailed description taken in conjunction with the accompanying drawings in which:
The detailed description explains the preferred embodiments of the invention, together with advantages and features, by way of example with reference to the drawings.
The system 101 may communicate with other computers or networks of computers by way of a network adapter capable of communicating with a network 109. Example network adapters are communications channels, token ring, Ethernet or modems. Alternatively, the workstation 101 may communicate using a wireless interface, such as a CDPD (cellular digital packet data) card. The workstation 101 may be associated with such other computers in a Local Area Network (LAN) or a Wide Area Network (WAN), or the workstation 101 can be a client in a client/server arrangement with another computer, etc. All of these configurations, as well as the appropriate communications hardware and software, are known in the art.
Still referring to
Software programming code which embodies the present invention is typically accessed by the processor 106 of the system 101 from long-term storage media 107, such as a CD-ROM drive or hard drive. The software programming code may be embodied on any of a variety of known media for use with a data processing system, such as a diskette, hard drive, or CD-ROM. The code may be distributed (deployed) on such media, or may be distributed to users from the memory or storage of one computer system over a network to other computer systems for use by users of such other systems.
Alternatively, the programming code 111 may be embodied in the memory 105, and accessed by the processor 106 using the processor bus. Such programming code includes an operating system which controls the function and interaction of the various computer components and one or more application programs. Program code is normally paged from dense storage media 107 to high speed memory 105 where it is available for processing by the processor 106. The techniques and methods for embodying software programming code in memory, on physical media, and/or distributing software code via networks are well known and will not be further discussed herein.
In the following detailed description of the present invention, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be obvious to one skilled in the art that the present invention may be practiced without these specific details. In other instances well known methods, procedures, components, and circuits have not been described in detail as not to unnecessarily obscure aspects of the present invention.
Some portions of the detailed descriptions which follow are presented in terms of procedures, logic blocks, processing, and other symbolic representations of operations on data bits within a computer memory. These descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. A procedure, logic block, process, step, etc., is here, and generally, conceived to be a self-consistent sequence of steps or instructions leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated in a computer system. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.
It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussions, it is appreciated that throughout the present invention, discussions utilizing terms such as “processing” or “computing” or “calculating” or “determining” or “displaying” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.
In
In
In order to avoid computationally expensive operations, snapshots of the file are periodically saved throughout the life of the editing process. This may be user initiated or automatically created. In
In
In
In
In
In
When a user adds an action (through whatever interface is appropriate), that action is either added to the end of the list of actions in the history, or added after the currently selected action in the history. All computations affected by the action are redone—in the case of an appended action, merely the action itself would be computed. In the case of an inserted action, however, all active actions from the inserted action through the last active action would be recomputed. At any point, actions can be moved from their current position to a new position in the history, which again results in the minimal re-computation. Also, at any point an action can be deactivated or reactivated by a toggle, such as a check box (
An individual action's properties can be modified, most likely through a button or a right-click menu, either of which would display an action-specific dialog to edit the properties. Again, any necessary re-computations would be done after the modifications.
When a user has an acceptable series of actions, the user may choose to turn the actions into a script. This would be accomplished with a simple button click, and the script would be saved to some user-accessible location, and perhaps opened for editing.
Finally, if the user wishes to give insight into why a given action was performed, the user can select an action, and annotate the action. A typical interaction is to use a right-click menu for this operation. Some sort of visible indication of the annotation would be displayed so that users can know what steps have comments. Because a set of history actions can be saved as a script, they can be used across sessions of one application or shared between users to support a collaborative approach to data manipulation.
In the sequence of images in
In one embodiment, the actions performed 914924926928 on the selected 905 original data sets 906907908909910911 are accumulated in an action history record. The action history record can then be programmably manipulated to modify the sequence of actions or the actions themselves by operating on the action history record. The final step modifies the file by replacing the contents of the image with data calculated from the image itself. This action is different than just modifying the contents of the file. The result of the history list is shown in
In another scenario, the user modifies the images with a number of actions, but then realizes that an additional action (the Threshold action 924) needs to be inserted into the list of actions to achieve the desired result. The user selects the Black and White action 914, and inserts the Threshold action. In the first attempt, the user decides that the settings for the threshold need to be adjusted. The user adjusts these properties. The resulting images are recalculated and are now acceptable. The user turns all of the active actions 914924926928 into a script program module for future use. Only those actions that are enabled (in
In the preceding example, the action history record is accumulated for a plurality of data records. The functionality of the present invention is not limited to operating on a plurality of data records, the invention is advantageous when applied to a single data record. Furthermore, multiple action history records may be created, one for each selected data record but presented as a composite in an alternative view.
One embodiment of the history list is a sequence of actions. This could be stored in binary or human readable text form. Each action is composed of a unique action id, a name, a set of attributes for that action, whether or not it is enabled, and a pointer to a snapshot if it exists for this action in the sequence of actions. In addition, any action may include text and other meta-data fields that allow the action to be used as a self-explanatory teaching aid. This text field is an annotation that explains the rationale for a given action in the sequence. In addition, when saving a set of actions, a general description for the whole action set can be used to describe the script. As actions are added to the sequence, they are appended to this list of actions. The history can be saved out and the history file can be used in a number of ways. It can move with the file and be reused when opening the original file. This set of actions can then be used to undo actions across editing sessions. In addition, it can be converted to a script by removing unnecessary data (references to snapshots and disabled actions). This script can then be applied to other files and in the process, its history will now mirror the saved script that was applied. In addition, the history file can provide meta-data about design decisions through the annotation facility. The annotations can provide other users with relevant information about the edit actions that are taking place in the file.
Any actions on the history list itself, such as enabling, disabling, adding, deleting, inserting, copying and pasting, can be viewed as modifying this list of data elements. For example, by deleting an action, the system first removes the action from the history list but then it needs to recalculate the file based on the revised history. This might mean going back to the original file and processing all the remaining enabled actions in the history list. Alternatively, the system could use a saved snapshot and then proceed forward adding any actions not already incorporated into the snapshot, while at the same time removing the newly deleted action and any disabled actions.
When the user disables an action, processing the file is the same as deleting an action as described above. However, the action remains in the list and can be re-enabled in the future. If re-enabled, its transformations would modify the file accordingly.
The flow diagrams depicted herein are just examples. There may be many variations to these diagrams or the steps (or operations) described therein without departing from the spirit of the invention. For instance, the steps may be performed in a differing order, or steps may be added, deleted or modified. All of these variations are considered a part of the claimed invention.
While the preferred embodiment of the invention has been illustrated and described herein, it is to be understood that the invention is not limited to the precise construction herein disclosed, and the right is “reserved” to all changes and modifications coming within the scope of the invention as defined in the appended claims.
