The invention relates to computer and data entry operations. More specifically, the invention relates to capturing user interface information to recreate a state of the user interface at a later time or different place.
Database and data entry applications often have a large amount of information to present to a user. Presenting the information in an easy-to-understand arrangement that permits the user to add, query, modify and delete records efficiently, can contribute to improved productivity.
Some applications allow the user to customize the user interface so that frequently-used commands, controls and displays are placed in locations the user finds convenient, while seldom-used items and information that is not relevant or interesting to the user may be hidden to free screen area for other uses. Current systems may permit the user to save the positions of windows of a customized interface layout. However, additional refinements to user interface management may produce gains in convenience and productivity.
Embodiments of the invention are illustrated by way of example and not by way of limitation in the figures of the accompanying drawings in which like references indicate similar elements. It should be noted that references to “an” or “one” embodiment in this disclosure are not necessarily to the same embodiment, and such references mean “at least one.”
Embodiments of the invention convert a screen layout into a persistable (storable) form such as an Extensible Markup Language (“XML”) string representation. The stored layout or XML string can be used to recreate the original screen layout later, or on a different screen.
According to an embodiment of the invention, screen layout 100 is transformed into an intermediate form 150, which can be saved for later use or transmitted to a different location. The intermediate form may be, for example, a static data structure or an Extensible Markup language (“XML”) string. Later (or elsewhere), a similar user interface 160 can be recreated by processing intermediate form 150. Certain aspects of recreated interface 160 are identical: tiled panes 110, 120 and 130 are the same sizes and in the same relative locations, and a pop-up dialog window 180 appears in the same location as dialog window 140. However, some elements are different. For example, clock 125 shows a different “current” time 170; that portion of the screen is not simply a verbatim copy of the source screen. Text input field 135 retains its contents (the partial city name “Ch”) but dialog window 180 displays a different list of city names. Here, a city named “Chesapeake” has been added to the list, and a “scroll bar” 185 appears because the list of cities is longer than can be displayed within the dialog window 180. Thus, although recreated interface 160 is mostly similar to the original screen layout 100, some details are different. Recreated interface 160 is not a simple pixel-by-pixel or character-by-character copy of the original.
Once the desired screen layout is prepared, a screen analysis is triggered (220), for example, by pressing a predetermined key or selecting a menu option. The software components associated with presently-displayed user interface features are identified (230) and, for each component, data describing the software component's state are obtained (240) and converted to a persistable form (250). The data collected may include information such as the identity of the current user, the databases currently being accessed, the records being displayed, a history of recent user activity, and so on. Data describing any user interface features associated with the software component are also collected. For example, the position and size of tiled panes and/or overlapping windows, location of the mouse cursor, contents of any user-entry fields, and so on, may recorded.
If there are more software components to process (260), operations 240 and 250 are repeated. At the end of this process, data describing the internal state of one or more software functions or applications have been collected and converted into a persistable form, which can be stored or sent elsewhere, and processed to recreate the user interface at another place or time. If the persisted screen layout is saved, it may be assigned a name for easier identification, and may be stored in such a way that other users can use the layout themselves.
If there are more software components to process (360), the embodiment loops back to repeat operations 330, 340 and 350. Once all the software components described in the selected data structure have been (re)started and configured, the previously-stored user interface state is recreated.
The software components discussed in relation to
A user 400 interacts with a computer system by viewing a user interface 100 displayed on a monitor 410. The components of the user interface—windows, graphics, text, data entry fields, and so on—may be drawn and maintained by a user interface (“UI”) manager 420. Software applications 430 and 440 interact with the user through the UI manager 420. For example, application 430 may send text to be drawn on monitor 410, and UI manager 420 can position the text correctly and draw those portions of the text that are not offscreen or obscured by, for example, an overlapping window.
An application such as software application 440 may separate calculation and display functions as shown: back-end logic 443 may interact with a database 450 to store or retrieve information, and may rely on a library 446 of functions that interact with the UI manager 420 to present information to user 400 and obtain new data from user 400.
In some environments, software applications may execute on a remote machine and interact with user 400 through a software stub that communicates with UI manager 420.
The activities of an embodiment of the invention may be performed by a logical component identified in
According to the division of functionality described with reference to
An embodiment of the invention interacts with various entities such as software applications and a user interface (“UI”) manager, as outlined in reference to
By collecting information from the UI manager (or from a similar software entity that deals with basic user interface actions), an embodiment can save and restore both partially-completed and fully-completed data entry states. For example, text entry fields can be recreated with their contents at the time the user interface was saved, and menus, buttons and other interface items can be placed in the same state. Also, user interface fields that maintain a history of previously-entered values can be restored with the same history.
When an embodiment of the invention collects information about software application and user interface state, it may place it in a “persistable” or “static” form. In other words, the information is formatted so that it may conveniently be stored (for example, in a file or a database) or transmitted over a communication channel of limited capability (for example, electronic mail). Many techniques for converting arbitrary binary data into easy-to-store, easy-to-transmit form are known in the art. For example, BASE-64 encoding transforms raw binary data into a longer stream of characters chosen from a limited alphabet. The Extensible Markup Language (“XML”) is another text-based representation that may be used with an embodiment of the invention. XML can represent hierarchical data within a serial character stream (“string”), can be machine processed relatively easily, and, in many cases, can be examined and edited by hand (albeit with greater difficulty).
An XML string can be combined with a second XML string or fragment to create a modified XML string containing different data. For example, an XML string representing a user interface state, prepared as described with reference to
An embodiment of the invention may be a machine-readable medium having stored thereon instructions which cause a programmable processor to perform operations as described above. In other embodiments, the operations might be performed by specific hardware components that contain hardwired logic. Those operations might alternatively be performed by any combination of programmed computer components and custom hardware components.
A machine-readable medium may include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer), including but not limited to Compact Disc Read-Only Memory (CD-ROM), Read-Only Memory (ROM), Random Access Memory (RAM), and Erasable Programmable Read-Only Memory (EPROM).
The applications of the present invention have been described largely by reference to specific examples and in terms of particular allocations of functionality to certain hardware and/or software components. However, those of skill in the art will recognize that software and user interface states can also be captured, stored and recreated by software and hardware that distribute the functions of embodiments of this invention differently than herein described. Such variations and implementations are understood to be captured according to the following claims.