The present invention relates generally to computer software, and more particularly to the automatic storage and retrieval of the state of computer software depending on an application's or a document's particular context.
A Graphical User Interface, or GUI, is made up of what are commonly called ‘widgets.’ Widgets can be buttons, checkboxes, scrollbars, menu items, edit boxes or any other graphical element a user can have a direct interaction with using a mouse or other input device. When the user interacts with a widget, generally some result happens. When a user clicks on a bold button in a word processing application, for example, the user expects selected text to become bold.
GUI widgets are generally organized into containers or user-interface elements. There are a variety of different kinds of widget containers. One kind of container is a menu. Menus contain menu items which the user can select to perform some action. Menus are generally organized by category. For example, an edit menu might contain a series of menu items related to editing a document. Menus are generally ‘docked’ along the top of the screen, though in some applications they can be moved to the sides or bottom of the screen.
Another type of container for GUI widgets is a toolbar. A toolbar consists of a series of widgets grouped together, typically lined up one next to the other. Toolbars are also organized by category. An edit toolbar might contain a series of controls that allow the user to edit the contents of a document. Toolbars, like menus, generally appear ‘docked’ at the top of the screen, though in many applications they can be moved to the sides or bottom of the screen.
Another container for GUI widgets is a palette. A palette consists of a series of widgets grouped together in a floating container which can be moved anywhere on the screen. Palettes do not physically connect with any other element on the screen for example, they do not dock into a menu or any other part of the GUI. They float independently. In some applications, toolbars and menus can be ‘torn off,’ or dragged away, from the side of the screen and turned into palettes.
Toolbars, menus and palettes may contain redundant controls. Various controls on a toolbar or palette and menu items in a menu might perform identical operations. This allows a user to interact with the GUI according to his or her preference.
What these three types of widget containers—menus, toolbars and palettes—share in common is that they all have an instant effect. For example, clicking on a bold button will instantly change any selected text to bold. In this sense, menus, toolbars and palettes are called non-modal. The user can have a toolbar up, and can interact with the document or other parts of the application at the same time.
Another kind of widget container is a dialog box. Dialog boxes are similar to palettes in that they are floating windows containing a series of widgets. However, unlike palettes, toolbars and menus, dialog boxes are modal, meaning that when a dialog is up, the rest of the application is locked and inaccessible until the dialog box is dismissed. Changes made to a document or application using a dialog box are generally not applied until an ‘Apply’ or ‘OK’ button is pressed. Some newer applications also allow users to select a ‘Preview’ checkbox, allowing them to see how their changes will affect their work without actually committing to the changes.
When GUIs were first being developed, most of their functionality was hidden in modal dialog boxes. From a user perspective, this created a great disadvantage and inconvenience. A user would have to make changes in the dialog box, click OK, see how the changes looked, and then call the dialog box up again if more changes were needed. This process was tedious and inefficient.
As GUIs evolved, much of the functionality hidden in dialog boxes became exposed in toolbars, menus and palettes. Eventually, this brought about a new problem—a proliferation of toolbars, menus and palettes. In many applications today, there are so many of these non-modal widget containers available that an entire screen can be filled with them, obscuring a document completely.
Practically speaking, there is rarely a user that needs all the toolbars, menus and palettes available in an application at once. Instead, the user calls up the needed widget container when he or she is doing work it is useful for. If, for example, a user is drawing shapes in a word-processing application, the user brings up the drawing palette while they draw. When the user is finished drawing, the palette is dismissed.
However, this frequent invocation and dismissal of toolbars and palettes itself can become a problem. In more sophisticated applications such as those used for desktop publishing or computer graphics, the user may have to interact with different palettes every few clicks. The user must constantly hide and show palettes and toolbars, and must often move palettes around to accommodate new contexts.
Because of these problems, many users choose to keep multiple palettes open at all times. This creates a cluttered user interface which gives the user a limited view of the document they are actually working on.
Palettes, menus and toolbars also pose another problem. In applications which require frequent interaction with palettes, menus and toolbars, the user is constantly moving a cursor from the object in the document being worked on to the needed palette. This forces the user to constantly move the pointer back and forth, either to move the palette to a more convenient location or to access needed widgets. Such constant mouse motion can cause repetitive stress injuries to users. There is therefore a need in the art for GUIs which require less mouse or pointer-device movements.
Users are also faced with the problem of having to manually and repetitively retrieve settings in an application depending on the type of work they are doing. For example, when a user is working with text in a page layout application, they may have a series of settings they prefer for text. When working with graphics, there may be a different series of settings they prefer. These settings may include layout of the GUI as well as such things as default font size, default brush size, and other application specific settings. Having to manually and repetitively change these settings can be tedious, especially when the settings being changed are the same every time. There is therefore a need in the art for a way to automatically save and invoke application settings based on the kind of work the user is doing, which is to say the current context of the application.
Prior art has permitted users to save a series of settings or preferences and recall them at will. Adobe applications, for example, have a feature called ‘Workspaces,’ which allows users to save and restore different palette settings. However, they still have to manually save and invoke these settings, so the problem is simply shifted, not resolved.
Another problem the user is faced with is finding the right toolbar, palette or menu for the problem at hand. Modern-day software applications might offer hundreds of different functions, each with an associated widget or series of widgets. The user might have to invoke and dismiss multiple palettes just to find the widget they need. It can be a tedious, trial and error process. There is therefore also a need in the art for GUIs which automatically organize user-interface elements.
Prior art has tried to address these problems by allowing toolbars and palettes to be customizable. This allows the user to group widgets to his or her liking, but it doesn't resolve the problem of the user having to manually call up specific toolbars and palettes when needed and dismiss them when finished.
Context-sensitive menus, in which a menu appears specifically geared towards the area clicked onscreen, are useful but limited—there are still a large number of unnecessary, and sometimes disabled, menu items available at any given time. Context-sensitive menus are also only applicable to menus, not to toolbars and palettes.
Some applications, such as the Microsoft Office suite, only show the most recently used menu items. This only hides from the user the most infrequently used menu items. This method is not sensitive to context. It may show some menu items which are not relevant to the current context, while hiding others that are.
In patent application publication number 20020101450, Microsoft Corp. proposes what is essentially one all-purpose palette whose contents shift as the user changes context within the application or document. First, the Microsoft proposal creates a shifting palette layout which can confuse users. Microsoft proposes a single palette whose contents and layout constantly shift. In many applications, especially those relating to the graphic design and computer animation fields, users are accustomed to and even dependent on palettes whose layout and content remain the same. Second, the Microsoft proposal does not take into account screen location. For the applications that Microsoft makes, screen location is not as critical as it is in desktop publishing, web design or other visual design applications where frequent pointer movement can lead to repetitive stress injury. Third, the architecture of the Microsoft proposal is geared primarily towards applications that allow customizing individual palettes.
Finally, it should be noted that Microsoft is not the first company to come up with the idea of a palette whose contents change as application or document context changes. The measurements palette in QuarkXPress has been displaying such behavior since the early 1990s.
Application users have a need for different settings in different contexts, particularly in more sophisticated applications such as computer graphics or desktop publishing. Different users have very different needs in the different application or document contexts—allowing them the ability to only modify certain settings is insufficient. There is a need in the art for a system that allows users to have any and all user settings saved and restored automatically.
Prior art has addressed the idea of modifying an application's interface based on context. In some applications, for example, a certain toolbar is only visible when the user enters a context in which it would be useful. However, those applications will only show and hide those widgets which are exclusive to that particular context. For example, in Microsoft Word, when editing a document outline, the Outline toolbar appears, and it disappears when the user is not in outline mode. However, there is no way to get the formatting toolbar, for example, to appear and disappear, or to have it change locations, when the user enters or exits Outline mode, even though the user rarely does formatting in outline mode. So those automatic modifications based on context that exist in prior art are limited to those widgets exclusive to a context.
The various embodiments of the present invention provide systems and methods for automatically collecting and storing application and document settings by examining an application's state when the user exits any particular context, and then restore the application and document state when the user re-enters that context. All features of the invention can be enabled or disabled individually or globally as the user wishes.
The invention can be embodied as a program module interacting with a specific application via that application's API, as a program module interacting with several applications via a shared code library, or as a program module which is actually contained in the main application's executable code.
Other embodiments are described and claimed.