Patent Application
20080295020
The present invention relates in general to the field of computers and other data processing systems, including hardware, software and processes. More particularly, the present invention pertains to appropriating and managing Graphical User Interface (GUI) real estate.
In a typical Graphical User Interface (GUI) desktop, the display area (“GUI real estate”) is usually occupied by application-specific windows, menus, a taskbar (that lets the user view and switch between the running operations) and other Operating System (OS) user interface elements. Since this desktop area is usually not large enough for all of the running applications to display their content at once, the OS allows the user to select a subset of applications to be hidden while they run in the background with their windows in minimized or hidden states. Most of the time, a single application occupies most of the display area, even though there are “insignificant” areas being displayed. That is, there are often areas in the application's GUI that are meaningless, such as large areas of monochromatic real estate that provide neither functionality nor information. Thus, such areas waste large areas of the GUI real estate.
To address the condition described above, presently disclosed are a computer-implementable method, system and computer media for allocating and managing insignificant areas of Graphical User Interface (GUI) real estate. In a preferred embodiment, the computer-implementable method includes identifying an insignificant area of GUI real estate in a GUI that is used by a first application. The identified insignificant area of GUI real estate is then populated with a graphical element of a second application.
The above, as well as additional purposes, features, and advantages of the present invention will become apparent in the following detailed written description.
The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further purposes and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, where:
With reference now to the figures, and in particular to
The main active window 103 also includes insignificant real estate areas 106a and 106b. These insignificant real estate areas may be deemed insignificant because, as depicted, they are monochromatic, thus suggesting that they contain no text, graphics, or other information, and similarly contain no active areas (such as buttons, or links to webpages, other applications, etc.). Note that insignificant real estate area 106b may stop at, or lie under, insignificant real estate area 106a.
Also part of GUI 102 is a task bar 108, which includes program buttons 110a, 110b, and 112 for minimized programs. As suggested by the figure, program button 112 is for a calculator accessory application.
Referring now to
The identification of which real estate areas are significant and/or insignificant, as well as the appropriation of insignificant real estate areas, may be performed by an operating system of a computer that is displaying the GUI 102. This identification and appropriation is performed in accordance with pre-defined criteria. Such criteria include, but are not limited to, an area being monochromatic, unchanging, unused, or containing “junk” information, such as text or graphic information that has been heuristically identified as being unimportant to a user. This determination of whether a real estate area is significant and/or insignificant may alternatively be performed by an application, such as a first application that is currently occupying a GUI, a second application that will be appropriating the insignificant GUI real estate, or a third application that is dedicated to identifying significant/insignificant GUI real estate. Note that the main window 103 is now larger than when shown in
Referring now to
Referring now to
If the identification of insignificant real estate is performed by an application, in a preferred embodiment an Application Program Interface (API) provided by the OS is used. That is, in one preferred embodiment, the application marks unused (insignificant) GUI real estate in the application's client space. The OS provides an API for the application to call. Whenever the client area (content displayed on the application's GUI) inside the application changes, the application calls the OS-provided API to re-register the unused GUI area. Thus, the application first determines that it wants to display a new GUI object. The application then calls the OS-provided system-level API, which includes the dimensions of the new GUI that the application wants to display. The OS then checks the graphics engine image map (pixel memory) and does a check to find the optimal location to suggest where the application should display the new GUI object (graphical element). The decision regarding where to display the new GUI object in the application's GUI may be based on Optical Character Recognition (OCR), such that the display of the new GUI object is based on the text information content found in a part of the application's GUI, which text information is deemed insignificant. Thus, if the text information in the application's GUI is insignificant, then the area in which this text information is displayed is likewise deemed insignificant. Alternatively, the location in the application's GUI for displaying the new GUI object may be based on monochromatic features, in which the entire identified area is the same color (e.g., grey), and thus conveys no textual or graphical information. Such monochromatic areas are also deemed “insignificant.”
In another embodiment, the OS can directly determine which GUI real estate is insignificant, in accordance with criteria described above. For example, the OS can automatically determine which geometric areas in the application's GUI are “insignificant.” This determination can be made periodically (according to some pre-determined time period), or can be made “on demand” whenever a new GUI object, including a GUI object from another application, needs to be displayed in GUI real estate previously owned by the first application's GUI.
Note that whether the OS or an application identifies an insignificant GUI real estate area, a pre-determined minimum size may be defined. That is, while examining the GUI real estate for insignificant areas, the OS or application may ignore areas that, although meet other criteria for “insignificance,” are physically too small to be useful to another GUI object.
After the insignificant real estate area is identified, the second application can then appropriate that area, and populate the appropriated area with a graphical element or elements that are associated with the second application (block 408), in a manner described above. In a preferred embodiment, the graphical element is automatically resized to fit within, or occupy all of, the previously insignificant real estate area. Alternatively, if the graphical element is too large, the graphical element can be displayed in the insignificant real estate and then overlap a portion of significant real estate area. If the graphical element has to overlap into significant real estate, then the portion that overlaps the significant real estate is preferably semi-transparent, such that the significant information originally displayed in the significant real estate area can still be seen (even if partially obscured.) Note that in one embodiment, the graphical element, of the second application, which is to populate the previously insignificant real estate area, may be an incoming element, such as a pop-up window that contains an incoming message to a user. The process ends at terminator block 410.
With reference now to
Client computer 502 is able to communicate with a service provider server 550 via a network 528 using a network interface 530, which is coupled to system bus 506. Network 528 may be an external network such as the Internet, or an internal network such as an Ethernet or a Virtual Private Network (VPN).
A hard drive interface 532 is also coupled to system bus 506. Hard drive interface 532 interfaces with a hard drive 534. In a preferred embodiment, hard drive 534 populates a system memory 536, which is also coupled to system bus 506. System memory is defined as a lowest level of volatile memory in client computer 502. This volatile memory may include additional higher levels of volatile memory (not shown), including but not limited to cache memory, registers, and buffers. Data that populates system memory 536 includes client computer 502's operating system (OS) 538 and application programs 544.
OS 538 includes a shell 540, for providing transparent user access to resources such as application programs 544. Generally, shell 540 is a program that provides an interpreter and an interface between the user and the operating system. More specifically, shell 540 executes commands that are entered into a command line user interface or from a file. Thus, shell 540 (as it is called in UNIX®), also called a command processor in Windows®, is generally the highest level of the operating system software hierarchy and serves as a command interpreter. The shell provides a system prompt, interprets commands entered by keyboard, mouse, or other user input media, and sends the interpreted command(s) to the appropriate lower levels of the operating system (e.g., a kernel 542) for processing. Note that while shell 540 is a text-based, line-oriented user interface, the present invention will equally well support other user interface modes, such as graphical, voice, gestural, etc.
As depicted, OS 538 also includes kernel 542, which includes lower levels of functionality for OS 538, including providing essential services required by other parts of OS 538 and application programs 544, including memory management, process and task management, disk management, and mouse and keyboard management.
Application programs 544 include a browser 546. Browser 546 includes program modules and instructions enabling a World Wide Web (WWW) client (i.e., client computer 502) to send and receive network messages to the Internet using HyperText Transfer Protocol (HTTP) messaging, thus enabling communication with service provider server 550.
Application programs 544 in client computer 502's system memory also include a Graphical User Interface Appropriation and Management Program (GUIAMP) 548, which includes code for implementing the processes and Graphical User Interfaces (GUIs) described in
In one embodiment, client computer 502 is able to download GUIAMP 548 from service provider server 550, preferably in an “on demand” basis.
Note that the hardware architecture for service provider server 550 may be substantially similar to that shown for client computer 502.
The hardware elements depicted in client computer 502 are not intended to be exhaustive, but rather are representative to highlight essential components required by the present invention. For instance, client computer 502 may include alternate memory storage devices such as magnetic cassettes, Digital Versatile Disks (DVDs), Bernoulli cartridges, and the like. These and other variations are intended to be within the spirit and scope of the present invention.
Note further that, in a preferred embodiment of the present invention, service provider server 550 performs all of the functions associated with the present invention (including execution of GUIAMP 548), thus freeing client computer 502 from using its own resources.
It should be understood that at least some aspects of the present invention may alternatively be implemented in a computer-useable medium that contains a program product. Programs defining functions of the present invention can be delivered to a data storage system or a computer system via a variety of signal-bearing media, which include, without limitation, non-writable storage media (e.g., CD-ROM), writable storage media (e.g., hard disk drive, read/write CD ROM, optical media), and communication media, such as computer and telephone networks including Ethernet, the Internet, wireless networks, and like network systems. It should be understood, therefore, that such signal-bearing media when carrying or encoding computer readable instructions that direct method functions in the present invention, represent alternative embodiments of the present invention. Further, it is understood that the present invention may be implemented by a system having means in the form of hardware, software, or a combination of software and hardware as described herein or their equivalent.
As described above, in one embodiment, the processes described by the present invention, including the functions of GUIAMP 548, are performed by service provider server 550. Alternatively, GUIAMP 548 can be deployed as software from service provider server 550 to client computer 502. This deployment may be performed in an “on demand” basis manner, in which GUIAMP 548 is only deployed when needed by client computer 502. In another embodiment, process software for the method so described may be deployed to service provider server 550 by another service provider server (not shown).
While the present invention has been particularly shown and described with reference to a preferred embodiment, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention. Furthermore, as used in the specification and the appended claims, the term “computer” or “system” or “computer system” or “computing device” includes any data processing system including, but not limited to, personal computers, servers, workstations, network computers, main frame computers, routers, switches, Personal Digital Assistants (PDA's), telephones, and any other system capable of processing, transmitting, receiving, capturing and/or storing data.
