US20110113486A1 - Credentialing User Interface for Gadget Application Access - Google Patents

Abstract

An approach is provided to receive a selection of a displayed window from a group of displayed windows that are visible on a display. The displayed window corresponds to a software application and the displayed window is displayed at a location on the display. Another displayed window is shown visually animating and forming from the first displayed window. An authentication input dialog is displayed on the second displayed window, with the displayed authentication input dialog corresponding to the software application. Authentication data is received at the authentication input dialog and is authenticated.

Description

REFERENCE TO PROVISIONAL APPLICATION
• This application is a non-provisional patent application claiming benefit to provisional patent application No. 61/259,985 which was filed on Nov. 10, 2009.
BACKGROUND OF THE INVENTION
• 1. Technical Field
• Subject matter disclosed herein relates to an approach that provides multiple user interface modes to a user of an information handling system.
• 2. Description of the Related Art
• Modern information handling systems typically employ a user interface (UI), such as a graphical user interface (GUI) that allows a user to operate the information handling system often with little or no formal computer training. These information handling system can include traditional computer systems, hand held devices, such as personal digital assistants (PDAs) and media players, gaming systems, household appliances, office equipment, and other devices. Traditional GUI systems include GUI components such as icons and windows. An icon is a small pictogram that often represents a computer function, such as an application program or program function. Users select icons in order to execute the desired program or function. A window is an area displayed on a hardware display that displays content related to a program or function independently from the rest of the visible screen.
SUMMARY
• An approach is provided to receive a selection of a displayed window from a group of displayed windows that are visible on a display. The displayed window corresponds to a software application and the displayed window is displayed at a location on the display. Another displayed window is shown visually animating and forming from the first displayed window. An authentication input dialog is displayed on the second displayed window, with the displayed authentication input dialog corresponding to the software application. Authentication data is received at the authentication input dialog and is authenticated.
• The foregoing is a summary and thus contains, by necessity, simplifications, generalizations, and omissions of detail; consequently, those skilled in the art will appreciate that the summary is illustrative only and is not intended to be in any way limiting. Other aspects, inventive features, and advantages of the present invention, as defined solely by the claims, will become apparent in the non-limiting detailed description set forth below.
BRIEF DESCRIPTION OF THE DRAWINGS
• Embodiments of the present invention may be better understood by referencing the accompanying drawings, wherein:
• FIG. 1 is a block diagram of a data processing system in which the methods described herein can be implemented;
• FIG. 2 provides an extension of the information handling system environment shown inFIG. 1 to illustrate that the methods described herein can be performed on a wide variety of information handling systems which operate in a networked environment;
• FIG. 3 is a diagram showing an initial logon screen used to verify access of a user before accessing data and processes provided by the information handling system;
• FIG. 4 is a diagram showing a grid display screen used to display a certain number of like-sized windows and an icon ribbon used to select additional applications;
• FIG. 5 is a diagram showing a mixed mode display screen used to display one large window and a number of like-sized vertically oriented windows;
• FIG. 6 is a diagram showing a fullscreen display screen used to display a selected application in a full screen;
• FIG. 7 is a diagram showing an application authentication flip screen where application authentication data is entered in order to use the selected application;
• FIG. 8 is a flowchart showing steps taken to manage the graphical user interface;
• FIG. 9 is a flowchart showing steps taken to handle the logon screen used to access the information handling system;
• FIG. 10 is a flowchart showing steps taken to handle and display the grid display screen;
• FIG. 11 is a flowchart showing steps taken to handle and display the mixed-mode display screen;
• FIG. 12 is a flowchart showing steps taken to handle and display the fullscreen display;
• FIG. 13 is a flowchart showing steps taken to perform particular functions, including handling application logon processing; and
• FIG. 14 is a diagram showing a mixed mode display screen with user management functionality of the vertically scrollable window area.
DETAILED DESCRIPTION
• Certain specific details are set forth in the following description and figures to provide a thorough understanding of various embodiments of the invention. Certain well-known details often associated with computing and software technology are not set forth in the following disclosure, however, to avoid unnecessarily obscuring the various embodiments of the invention. Further, those of ordinary skill in the relevant art will understand that they can practice other embodiments of the invention without one or more of the details described below. Finally, while various methods are described with reference to steps and sequences in the following disclosure, the description as such is for providing a clear implementation of embodiments of the invention, and the steps and sequences of steps should not be taken as required to practice this invention. Instead, the following is intended to provide a detailed description of an example of the invention and should not be taken to be limiting of the invention itself. Rather, any number of variations may fall within the scope of the invention, which is defined by the claims that follow the description.
• The following detailed description will generally follow the summary of the invention, as set forth above, further explaining and expanding the definitions of the various aspects and embodiments of the invention as necessary. To this end, this detailed description first sets forth a computing environment inFIG. 1 that is suitable to implement the exemplary software and/or hardware techniques associated with the invention. A networked environment is illustrated inFIG. 2 as an extension of the basic computing environment, to emphasize that modern computing techniques can be performed across multiple discrete devices.
• FIG. 1 illustratesinformation handling system100, which is a simplified example of a computer system capable of performing the computing operations described herein.Information handling system100 includes one ormore processors110 coupled toprocessor interface bus112.Processor interface bus112 connectsprocessors110 to Northbridge115, which is also known as the Memory Controller Hub (MCH). Northbridge115 connects tosystem memory120 and provides a means for processor(s)110 to access the system memory.Graphics controller125 also connects to Northbridge115. In one embodiment, PCI Expressbus118 connects Northbridge115 tographics controller125.Graphics controller125 connects todisplay device130, such as a computer monitor.
• Northbridge115 and Southbridge135 connect to each other usingbus119. In one embodiment, the bus is a Direct Media Interface (DMI) bus that transfers data at high speeds in each direction between Northbridge115 and Southbridge135. In another embodiment, a Peripheral Component Interconnect (PCI) bus connects the Northbridge and the Southbridge. Southbridge135, also known as the I/O Controller Hub (ICH) is a chip that generally implements capabilities that operate at slower speeds than the capabilities provided by the Northbridge. Southbridge135 typically provides various busses used to connect various components. These busses include, for example, PCI and PCI Express busses, an ISA bus, a System Management Bus (SMBus or SMB), and/or a Low Pin Count (LPC) bus. The LPC bus often connects low-bandwidth devices, such asboot ROM196 and “legacy” I/O devices (using a “super I/O” chip). The “legacy” I/O devices (198) can include, for example, serial and parallel ports, keyboard, mouse, and/or a floppy disk controller. The LPC bus also connects Southbridge135 to Trusted Platform Module (TPM)195. Other components often included in Southbridge135 include a Direct Memory Access (DMA) controller, a Programmable Interrupt Controller (PIC), and a storage device controller, which connects Southbridge135 tononvolatile storage device185, such as a hard disk drive, usingbus184.
• ExpressCard155 is a slot that connects hot-pluggable devices to the information handling system.ExpressCard155 supports both PCI Express and USB connectivity as it connects toSouthbridge135 using both the Universal Serial Bus (USB) the PCI Express bus.Southbridge135 includes USB Controller140 that provides USB connectivity to devices that connect to the USB. These devices include webcam (camera)150, infrared (IR)receiver148, keyboard andtrackpad144, andBluetooth device146, which provides for wireless personal area networks (PANs). An external device can wirelessly connect toBluetooth device146 and transmit data to the information handling system, in whichcase Bluetooth device146 acts as a data receiver for the information handling system. USB Controller140 also provides USB connectivity to other miscellaneous USB connecteddevices142, such as a mouse, removablenonvolatile storage device145, modems, network cards, ISDN connectors, fax, printers, USB hubs, and many other types of USB connected devices. While removablenonvolatile storage device145 is shown as a USB-connected device, removablenonvolatile storage device145 could be connected using a different interface, such as a Firewire interface, etcetera. When an external device is connected to USB controller140 that is capable of receiving data from the information handling system, the USB controller acts as a data receiver.
• Wireless Local Area Network (LAN)device175 connects to Southbridge135 via the PCI orPCI Express bus172.LAN device175 typically implements one of the IEEE 802.11 standards of over-the-air modulation techniques that all use the same protocol to wireless communicate betweeninformation handling system100 and another computer system or device.Optical storage device190 connects toSouthbridge135 using Serial ATA (SATA)bus188. Serial ATA adapters and devices communicate over a high-speed serial link. The Serial ATA bus also connectsSouthbridge135 to other forms of storage devices, such as hard disk drives.Audio circuitry160, such as a sound card, connects toSouthbridge135 viabus158.Audio circuitry160 also provides functionality such as audio line-in and optical digital audio inport162, optical digital output andheadphone jack164,internal speakers166, andinternal microphone168.Ethernet controller170 connects toSouthbridge135 using a bus, such as the PCI or PCI Express bus.Ethernet controller170 connectsinformation handling system100 to a computer network, such as a Local Area Network (LAN), the Internet, and other public and private computer networks. When an external device connects to the information handling system usingwireless LAN device175 or wired LAN via a connection toEthernet controller170, and when the external device sends data to the information handling system, theLAN device175 performs the role of a data receiver. Indeed, any device that can route or transmit data to the information handling system via a component of the information handling system acts as an external device and the component that receives such data acts as a data receiver of the information handling system.
• WhileFIG. 1 shows one information handling system, an information handling system may take many forms. For example, an information handling system may take the form of a desktop, server, portable, laptop, notebook, or other form factor computer or data processing system. In addition, an information handling system may take other form factors such as a personal digital assistant (PDA), a gaming device, ATM machine, a portable telephone device, a communication device or other devices that include a processor and memory.
• The Trusted Platform Module (TPM195) shown inFIG. 1 and described herein to provide security functions is but one example of a hardware security module (HSM). Therefore, the TPM described and claimed herein includes any type of HSM including, but not limited to, hardware security devices that conform to the Trusted Computing Groups (TCG) standard, and entitled “Trusted Platform Module (TPM) Specification Version 1.2.” The TPM is a hardware security subsystem that may be incorporated into any number of information handling systems, such as those outlined inFIG. 2.
• FIG. 2 provides an extension of the information handling system environment shown inFIG. 1 to illustrate that the methods described herein can be performed on a wide variety of information handling systems that operate in a networked environment. Types of information handling systems range from small handheld devices, such as handheld computer/mobile telephone210 to large mainframe systems, such asmainframe computer270. Examples ofhandheld computer210 include personal digital assistants (PDAs), personal entertainment devices, such as MP3 players, portable televisions, and compact disc players. Other examples of information handling systems include pen, or tablet,computer220, laptop, or notebook,computer230,workstation240,personal computer system250, andserver260. Other types of information handling systems that are not individually shown inFIG. 2 are represented byinformation handling system280. As shown, the various information handling systems can be networked together using computer network200. Types of computer network that can be used to interconnect the various information handling systems include Local Area Networks (LANs), Wireless Local Area Networks (WLANs), the Internet, the Public Switched Telephone Network (PSTN), other wireless networks, and any other network topology that can be used to interconnect the information handling systems. Many of the information handling systems include nonvolatile data stores, such as hard drives and/or nonvolatile memory. Some of the information handling systems shown inFIG. 2 depicts separate nonvolatile data stores (server260 utilizesnonvolatile data store265,mainframe computer270 utilizesnonvolatile data store275, andinformation handling system280 utilizes nonvolatile data store285). The nonvolatile data store can be a component that is external to the various information handling systems or can be internal to one of the information handling systems. In addition, removablenonvolatile storage device145 can be shared among two or more information handling systems using various techniques, such as connecting the removablenonvolatile storage device145 to a USB port or other connector of the information handling systems.
• FIG. 3 is a diagram showing an initial logon screen used to verify access of a user before accessing data and processes provided by the information handling system.Initial logon screen300 is presented to the user when the user returns to the system after locking the system during a previous use. A “welcome back” message is displayed to the user and the user is prompted to enteruser name310 andpassword320. When these items are entered, the user pressesGUI control330 whereupon the user's name and password are verified before allowing the user to access the information handling system. In addition, if the user forgets his or her password, a password hint can be requested by selectingGUI control340. GUIcontrol command buttons350 and360 are selected by the user to, respectively, shutdown the information handling system or restart the information handling system.
• FIG. 4 is a diagram showing a grid display screen used to display a certain number of like-sized windows and an icon ribbon used to select additional applications.Display screen400 is displaying the grid display. In one embodiment, the grid display is called the “six space” view as there are sixwindows410 visible ondisplay screen400. Other embodiments may utilize a different number of windows. Each of the windows, however, is a fixed, predetermined size so that the grid of windows appears with each window in the grid being the same size (width and height). Each window includes its associatedicon420 and these same icons can be found inicon ribbon bar470. More than the visible number of windows can be utilized by the user. In order to see other opened windows, the user scrolls left or right using GUI controls450 and460, respectively. While left/right scrolling is shown with the grid view, other embodiments may be developed with the grid scrolling up and down. Also ondisplay screen400 is day/time indicator440 andstatus icons445. In addition,search control435 allows the user to enter a search parameter into the GUI control and search for an item of interest.Multi-view icon430, when selected, allows the user to exit the grid display and enter the multi-view display shown inFIG. 5.Full screen icon425 may be applicable for some of the windows, such as a multimedia application displayed in one of the windows. Application “1” located in the lower left cell of the grid includes a full screen icon. If the user selectsfull screen icon425, then application “1” is displayed in fullscreen mode (seeFIG. 6). For example, application “1” might be a multimedia application to play multimedia content, such as a movie or video stream. When the user selectsfull screen icon425, then the multimedia application would be displayed in fullscreen mode as shown inFIG. 6.Icon ribbon bar470 shows icons associated with available applications. In the example shown, applications “5”, “4”, “3”, “9”, “21”, and “1” are visible ingrid display400. These applications correspond with icons “1” through “16” shown inicon ribbon bar470. Note, however, that the icon for application “21” is not currently visible inicon ribbon bar470. In order to see the corresponding icon inribbon bar470, the user scrolls the ribbon bar using GUI controls480 and490. WhenGUI control480 is selected, the icons are scrolled to the left and whenGUI control490 is selected, the icons are scrolled to the right. In the example, there is enough room inribbon bar470 to display16 icons. Whenright GUI control490 is selected, then the next 16 icons are displayed (e.g., “17” through “64”). In one embodiment, if there are not enough non-displayed icons to fill all 16 spots, then the icons wrap to display other icons that are currently being displayed. For example, if there are 26 current applications and the user selectsright GUI control480, then the next 10 icons are displayed on the left side of ribbon bar for applications “17” through “26” and remaining spots on the right side ofribbon bar470 display icons for applications “1” through “6.” Likewise, using the 26 icon example, if the user selected theright GUI control480, then icons for applications “17” through “26” would be displayed on the right side of ribbon bar and icons for applications “11” through “16” would be displayed on the left side ofribbon bar470. If the user wants to open a window for an application, the user simply selects the icon corresponding to the desired application fromicon ribbon bar470. For example, if the user wishes to open application “2”, then the user simply selects the icon labeled “2” fromribbon bar470. In one embodiment, the user can insert the window of the application in a desired grid location by selecting the icon and dragging it to the place ongrid400 where the use wants it to appear (e.g., between the “4” and the “3” applications). If, as in the example shown, the grid already has a full compliment of windows (e.g., six windows in the example shown), then one of the windows is shifted off ofgrid display400. For example, if application “2” is opened between applications “4” and “3”, then application “3” is shifted off ofvisible display grid400. If the user wants to view the window for application “3”, the user scrolls right usingGUI arrow control460. Windows that are displayed ingrid400 can be scrolled left and right similar to the ribbon bar control described above. In addition, similar to the ribbon bar, the windows displayed ingrid400 can “wrap” so that the user can cycle through all of the opened windows by repeatedly selecting the same GUI arrow control (eithercontrol450 or control460). In one embodiment,full screen icon426 appears separate from an individual window. By selectingicon426, the currently selected window (the focus window) is displayed in fullscreen mode (seeFIG. 6).
• FIG. 5 is a diagram showing a mixed mode display screen used to display one large window and a number of like-sized vertically oriented windows.Mixed mode display500 is arranged with onelarge window510 andsmaller windows410 arranged vertically. The GUI arrow controls are now vertical (GUI controls550 (up) and560 (down)) and allow the user to scrollwindows410 up and down as needed (similar to the windows ingrid400 shown inFIG. 4).GUI control555 is used to managewindows400 that appear in the vertical scrollable area as well as control the order in which the windows appear (seeFIG. 14 and corresponding text for processing details).GUI control530 is selected by the user in order to view the grid display shown inFIG. 4. The application (in this case application “9”) shown inlarge window510 is the application of focus. In one embodiment, the user selects awindow410 from the vertically scrollable display in order to make a different application appear inlarge window510. For example, if the user selects application “3” (the top window in the vertically scrollable display), then application “3” will appear inlarge window510 and application “9” will be shown in asmaller window410 in the vertically scrollable area.
• FIG. 6 is a diagram showing a fullscreen display screen used to display a selected application in a full screen.Full screen display600 includes a singlelarge window610 where the selected application is displayed. In one embodiment,fullscreen display600 includes both a cinema graphic mode for displaying multimedia content, such as movies and video streams, inlarge window610 as well as a full screen mode for displaying application content, such as word processors, spreadsheets, and Web browsers, inlarge window610.Controls640 are either visible or hidden. When the controls are needed, the user requests the controls by selecting an area on the screen or pressing a key on the keyboard whereupon controls640 appear to allow the user to control the content being displayed (e.g., previous, rewind, play, stop, pause, next, fast forward, and audio level controls).Controls640 are typically used for multimedia content. In addition,icons650,660,530, and430 appear when requested by the user.Icon650 is selected to expand the size oflarge window610 whileicon660 is selected to reduce the size oflarge window610.Icon530 is used to change the view to grid mode, as shown inFIG. 4, andicon430 is used to change the view to mixed mode, as shown inFIG. 5.
• FIG. 7 is a diagram showing an application authentication flip screen where application authentication data is entered in order to use the selected application. When authentication is required, such as when a user is requesting to enter a secure Web site, the window appears to “flip” over with the “backside” of the window used to enter authentication data. “Flipping” is one example of animating the display of the backside of the window forming from the frontside of the window. In the example shown application “5” (seeFIG. 4) such as an email site, has been selected, however the user needs to be authenticated before the requested application can be fully used by the user. The window appears to flip over withauthentication window700 appearing. In the example shown, the authentication data being requested includes aname710 andpassword720. When this data is provided, the user selects “sign in”GUI control730 which passes the provided name and password to the application for processing. If the provided data is authentication, then the window will appear to “flip” back over to reveal the unlocked application (e.g., the email program with the user's emails now visible). To close the window, the user selects “close”GUI control740. In one embodiment, as shown,authentication window700 appears in an inverted format (e.g., dark background and white letters instead of light background and dark letters) in order to distinguish authentication windows from other windows.
• FIG. 8 is a flowchart showing steps taken to manage the graphical user interface. Processing commences at800 whereupon, at step810, a user action is detected. Atstep820, the current mode of the device is detected. The modes described inFIGS. 3-6 include locked mode (FIG. 3), grid mode (FIG. 4), mixed mode (FIG. 5), and fullscreen mode (FIG. 6). A determination is made as to whether the system is currently in locked mode (decision830). If the system is in locked mode, thendecision830 branches to the “yes” branch whereupon, at predefined process840, the logon screen is handled (seeFIG. 9 and corresponding text for processing details). On the other hand, if the system is not in locked mode, thendecision830 branches to the “no” branch whereupon a determination is made as to whether the system is currently in the grid mode (decision850). If the system is currently in grid mode, thendecision850 branches to the “yes” branch whereupon, at predefined process860, the grid mode interface is handled (seeFIG. 10 and corresponding text for processing details). On the other hand, if the grid mode is not the current mode, thendecision850 branches to the “no” branch whereupon a determination is made as to whether the current mode is mixed mode (decision870). If the current mode is the mixed mode, thendecision870 branches to the “yes” branch whereupon, at predefined process875, the mixed mode interface is handled (seeFIG. 11 and corresponding text for processing details). On the other hand, if the current mode is not mixed mode, thendecision870 branches to the “no” branch whereupon a determination is made as to whether the current mode is fullscreen mode (decision880). If the current mode is fullscreen mode, thendecision880 branches to the “yes” branch whereupon, at predefined process890, the fullscreen mode interface is handled (seeFIG. 12 and corresponding text for processing details). On the other hand, if the current mode is not fullscreen mode, thendecision880 branches to the “no” branch. After the user action has been handed by one of the predefined processes, processing waits for the next user action at895. When the next user action is received, processing loops back to receive and process the user's action as described above.
• FIG. 9 is a flowchart showing steps taken to handle the logon screen used to access the information handling system. Processing commences at900 whereupon, at step910, the logon screen is displayed (seeFIG. 3 for an example of a system logon screen). A determination is made as to whether the user has entered authentication data, such as a name and password (decision920). If the user has entered authentication data, thendecision920 branches to the “yes” branch whereupon, atstep925, the system attempts to authenticate the user using the provided authentication data (e.g., the user's name and password). A determination is made as to whether the user is successfully authenticated (decision930). If the user is successfully authenticated, thendecision930 branches to the “yes” branch whereupon a determination is made as to whether this is the user's initial use of the system (decision935). If this is the user's initial use of the system, then decision935 branches to the “yes” branch whereupon, atstep940, the system displays Display default interface (e.g. grid mode interface) and load/display ribbon as needed (seeFIGS. 4-5 for examples of possible default interfaces). Processing then returns to the calling routine (FIG. 8) at945. Returning to decision935, if this is not the user's initial use of the system, then decision935 branches to the “no” branch whereupon, at step950, the system displays the last used interface (seeFIGS. 4-6 for examples of possible last used interfaces). Processing then returns to the calling routine (FIG. 8) at955. Returning todecision930, if the user is not authenticated (authentication failed), thendecision930 branches to the “no” branch whereupon, atstep960, an error is displayed to the user indicating that the user provided incorrect authentication data. Processing then returns to the calling routine (FIG. 8) at965. Returning todecision920, if the user is not attempting to be authenticated, thendecision920 branches to the “no” branch whereupon a determination is made as to whether is requesting a password hint (decision970). If the user is requesting a password hint, thendecision970 branches to the “yes” branch whereupon, atstep975, the password hint (if available) is displayed to the user. Processing then returns to the calling routine (FIG. 8) at980. Returning todecision970, if a password hint is not being requested, thendecision970 branches to the “no” branch whereupon, atstep990, some other function being requested by the user (e.g., shutdown, restart, etc.) is performed. Processing then returns to the calling routine (FIG. 8) at995.
• FIG. 10 is a flowchart showing steps taken to handle and display the grid display screen. Processing commences at1000 whereupon a determination is made as to whether the grid mode interface is being initialized (decision1004). If the grid mode interface is being initialized, thendecision1004 branches to the “yes” branch whereupon steps1008 through1028 are performed. Atstep1008, a scrollable, fixed window grid pattern is set so that each application window displayed is substantially equal in size (width and height) and the windows are fixed so that they are not adjustable by the user. In one embodiment, the grid, as shown inFIG. 4, is three windows horizontally by two windows vertically for a total of six windows visible on the screen at a time. Other screen sizes may permit different configurations of fixed windows (e.g., 4 by 3, 6 by 4, etc.). Atstep1012, a scrollable, fixed sized icon ribbon bar is displayed. In one embodiment, the icon ribbon bar is displayed at the bottom of the screen. Atstep1016, icons are loaded (displayed) in the fixed ribbon bar. In one embodiment, the icons that are loaded are those applications available to the user. In another embodiment, the loaded icons have previously been identified as the user's “favorites,” and in another embodiment, the loaded icons are those applications that are running in the computer system. The ribbon bar (seeFIG. 4) is scrollable so that if more icons are loaded than can be displayed on the area of the visible ribbon bar, the icons can be scrolled (e.g., left and right) so that other icons appear on the ribbon bar. At step1020, status icons and the time and date are displayed on the grid mode interface. Atstep1024, a mixed mode icon is displayed (e.g., on the upper right portion of the screen). The mixed mode icon, when selected, allows the user to view the mixed mode interface (seeFIG. 5). In one embodiment, a fullscreen icon is also displayed along with the mixed mode icon so that, when selected by the user, the application window that currently has focus is presented in a full screen interface (e.g., a multimedia application, etc.). Initialization processing returns to the calling routine at1028.
• Returning todecision1004, if the grid mode interface is not being initialized, thendecision1004 branches to the “no” branch whereupon a determination is made as to whether the user has selected an icon from the icon ribbon bar (decision1032). If the user has selected an icon from the icon ribbon bar, thendecision1032 branches to the “yes” branch whereupon, atstep1036, processing checks for the selected application in an existing fixed window that may or may not currently be visible on the display screen. A determination is made as to whether the application has already been loaded into a window (decision1040) If the application has already been loaded into a window, thendecision1040 branches to the “yes” branch whereupon a determination is made as to whether to create a new instance of the application (decision1044). Some applications can have several instances, such as multiple instances of a Web browser, that can each be displayed in separate windows. Other applications should only have a single instance of the program running in order to prevent issues such as data corruption if both instances are using the same database or data store. If the selected application can have multiple instances, thendecision1044 branches to the “yes” branch. Returning todecision1040, if the selected application has not yet been loaded, thendecision1040 branches to the “no” branch or if the application can have multiple instances (decision1044 branching to the “yes” branch), then a determination is made as to whether the available windows in the visible fixed grid (e.g., the six windows in a three by two grid) are all currently being used (decision1048). In one embodiment, the user drags the icon to the area of the grid interface where the user wants the selected application to appear and the other applications are moved in order to make room for the application at the position specified by the user's drag gesture. If all of the available visible windows are currently being used by an application, thendecision1048 branches to the “yes” branch whereupon, atstep1052, one of the fixed windows is moved to another (currently non-visible) page to make room for the application selected by the user. If the user wants to view the window that was moved, the user simply scrolls to the next page using one of the arrow GUI controls (see GUI controls450 and460 inFIG. 4). On the other hand, if the fixed grid is not full, thendecision1048 branches to the “no”branch bypassing step1052. At step1056, a new fixed window is created in the visible grid for the selected application. Atstep1060, the selected application is loaded into the newly created window. Returning todecision1044, if the selected application has already been loaded and a new instance of the application should not be created, thendecision1044 branches to the “no” branch whereupon, atstep1064, if needed, the grid is scrolled so that the selected application is visible in the displayed grid interface (e.g., if the selected application was not on the currently displayed page of the grid). Once the application is visible on the screen after eitherstep1060 or1064, then the focus is set to the window displaying the selected application. Keystrokes and other events are directed at the window with focus. Processing then returns at1072.
• Returning todecision1032, if a ribbon icon is not selected, thendecision1032 branches to the “no” branch whereupon a determination is made as to whether a window within the grid interface has been selected by the user (decision1076). If a window within the grid interface has been selected by the user, thendecision1076 branches to the “yes” branch whereupon, at step1078, focus is set to the window displaying the selected application. Keystrokes and other events are directed at the window with focus. Processing then returns at1080.
• Returning todecision1076, if a grid window has not been selected, thendecision1076 branches to the “no” branch whereupon a determination is made as to whether the mixed mode interface has been selected (decision1082, see, e.g.,mixed mode icon430 inFIG. 4). If the mixed mode interface has been requested, thendecision1082 branches to the “yes” branch whereupon, atpredefined process1084, the mixed mode interface is initialized (seeFIG. 11 and corresponding text for processing details). Processing then returns at1086.
• Returning todecision1082, if the mixed mode interface has not been requested, thendecision1082 branches to the “no” branch whereupon predefined process1088 is performed (seeFIG. 13 and corresponding text for processing details). Processing then returns to the calling routine at1090.
• FIG. 11 is a flowchart showing steps taken to handle and display the mixed-mode display screen. Processing commences at1100 whereupon a determination is made as to whether the mixed mode interface is being initialized (decision1105). If the interface is being initialized, thendecision1105 branches to the “yes” branch whereupon, at step1110 a fixed mixed mode interface layout is allocated and displayed on the available screen space. In the mixed mode layout, one window is a large window (seewindow510 inFIG. 5) and the other windows are smaller and scrollable (seewindows410 inFIG. 5). In one embodiment, as shown inFIG. 5, the smaller scrollable windows are arranged vertically and can be scrolled up and down using the respective GUI controls. At step1115, the window currently with focus is loaded into the large window and atstep1120 the other loaded applications are loaded intosmaller windows410. If more applications are loaded into smaller windows than can be displayed in the allocated small window space, then only a certain number of windows are visible with other windows becoming visible (and other visible windows no longer being visible) when the user selects the GUI controls for scrolling the small windows. At step1125, the time and date and other small status icons are displayed on the mixed mode window. Atstep1130, a grid mode icon is displayed (e.g., on the upper right portion of the screen). The grid mode icon, when selected, allows the user to view the grid mode interface (seeFIG. 4). In one embodiment, a fullscreen icon is also displayed along with the mixed mode icon so that, when selected by the user, the application window that currently has focus is presented in a full screen interface (e.g., a multimedia application, etc.). Initialization processing returns to the calling routine at1035.
• Returning todecision1105, if the mixed mode interface is not initializing, thendecision1105 branches to the “no” branch whereupon a determination is made as to whether one of the small windows (windows410 shown inFIG. 5) has been selected (decision1140). If a small window has not been selected, thendecision1140 branches to the “no” branch whereupon a determination is made as to whether the grid mode has been requested (e.g., by the user selecting the grid mode icon) atdecision1142. If the grid mode has been requested, thendecision1142 branches to the “yes” branch whereupon the grid mode is initialized at predefined process1144 (seeFIG. 10 and corresponding text for processing details). Processing then returns to the calling routine at1146. Returning todecision1142, if the grid mode has not been requested, thendecision1142 branches to the “no” branch whereuponpredefined process1148 is executed to handle the function requested by the user (seeFIG. 13 and corresponding text for processing details). Processing thereafter returns at1150.
• Returning todecision1140, if a small window has been selected, thendecision1140 branches to the “yes” branch whereupon a determination is made as to whether the user has requested (e.g., by use of a gesture such as a double-click) to display the application currently being displayed in the small window in the large window (decision1152). If the user has not requested to display the small window application in the large window, thendecision1152 branches to the “no” branch whereupon, atstep1154, focus is set to the selected small window and processing returns at1156. On the other hand, if the user has requested to display the small window application in the large window, thendecision1152 branches to the “yes” branch whereupon a determination is made as to whether either window (small or large) is currently playing multimedia content (decision1158). If neither is playing multimedia content, thendecision1158 branches to the “no” branch whereupon, atstep1160, the application displayed in the small window is displayed in the large window and the application displayed in the large window is displayed in the small window (the applications swap places on the screen). Processing then returns at1162.
• Returning todecision1158, if either window is playing multimedia content, thedecision1158 branches to the “yes” branch whereupon a determination is made as to whether the large window is currently playing multimedia content (decision1164). If the large window is currently playing multimedia content, thendecision1164 branches to the “yes” branch whereupon the application is paused (step1166) and a flag is set indicating that the application was paused during a swap operation. On the other hand, if the application playing in the large window is not playing multimedia content, thendecision1164 branches to the “no” branch bypassing step1166. Atstep1168, the application playing in the large window is displayed in the selected small window. Atstep1170, the application that was playing in the small window is displayed in the large window. A determination is made as to whether the application that was displayed in the small window (and is now displayed in the large window) is playing multimedia content where play should be resumed (e.g., by checking the flag set in step1166 when the application was previously swapped out) atdecision1172. If the application that was displayed in the small window (and is now displayed in the large window) is playing multimedia content that should be resumed, thendecision1172 branches to the “yes” branch whereupon, at step1174, playback of the multimedia content is resumed in the large window. On the other hand, if the small window is not playing multimedia content (or playing of the content should not be resumed), thendecision1172 branches to the “no” branch bypassing step1174. Processing then returns to the calling routine at1176.
• FIG. 12 is a flowchart showing steps taken to handle and display the fullscreen display. Processing commences at1200 whereupon a determination is made as to whether the fullscreen interface is being initialized (decision1205). If the fullscreen interface is being initialized, thendecision1205 branches to the “yes” branch whereupon, atstep1210, the selected application (the window that had the focus) is displayed in fullscreen mode and other smaller windows are not displayed on the display screen. A determination is made as to whether to display controls, such as fast forward, rewind, and other controls (decision1215). If the controls should be displayed, thendecision1215 branches to the “yes” branch whereupon, atstep1220, the fullscreen mode controls are displayed. In one embodiment, a cinema view and a fullscreen view are two different views that can be displayed in fullscreen mode. In cinema view, multimedia controls such as fast forward, play stop rewind previous, next, and volume controls are displayed. Other controls, such as those to switch to other view modes, such as grid mode and mixed mode, are also displayed (seeFIG. 6 for examples of controls that are displayed in fullscreen mode). On the other hand, if fullscreen controls are not being displayed, thendecision1215 branches to the “no” branch whereupon, atstep1225, the fullscreen mode controls are hidden from view. Processing then returns to the calling routine at1230.
• Returning todecision1205, if the fullscreen mode is not being initialized, thendecision1205 branches to the “no” branch whereupon a determination is made as to whether the user has requested to toggle the display of controls on the fullscreen display (decision1235). If the user has requested to toggle the display of the controls, thendecision1235 branches to the “yes” branch whereupon a determination is made as to whether the controls are currently visible on the display (decision1240). If the controls are currently visible, thendecision1240 branches to the “yes” branch whereupon, atstep1245, the fullscreen controls are hidden from view. On the other hand, if the controls are not currently visible, thendecision1240 branches to the “no” branch whereupon, atstep1250, the fullscreen mode controls are displayed on the display screen. As previously discussed, in one embodiment, a cinema view and a fullscreen view are two different views that can be displayed in fullscreen mode. In cinema view, multimedia controls such as fast forward, play stop rewind previous, next, and volume controls are displayed. Other controls, such as those to switch to other view modes, such as grid mode and mixed mode, are also displayed (seeFIG. 6 for examples of controls that are displayed in fullscreen mode). Processing then returns to the calling routine at1255.
• Returning todecision1235, if the user has not requested to toggle the display of fullscreen controls, thendecision1235 branches to the “no” branch whereupon a determination is made as to whether the user has requested to view grid mode (decision1260, seeFIG. 4 for an example of the grid mode). If the user has requested to view the grid mode, thendecision1260 branches to the “yes” branch whereupon, atpredefined process1265, the grid mode is initialized (seeFIG. 10 and corresponding text for processing details). Processing then returns to the calling routine at1270.
• Returning todecision1260, if the user is not requesting to view grid mode, thendecision1260 branches to the “no” branch whereupon a determination is made as to whether the user is requesting to view the mixed mode (decision1275, seeFIG. 5 for an example of the mixed mode). If the user is requesting to view mixed mode, thendecision1275 branches to the “yes” branch whereupon, atpredefined process1280, mixed mode is initialized (seeFIG. 11 and corresponding text for processing details). Processing then returns to the calling routine at1285. On the other hand, if the user is not requesting to view the mixed mode, thendecision1275 branches to the “no” branch whereupon, at predefined process1290, some other function requested by the user is performed (seeFIG. 13 and corresponding text for processing details). Processing then returns to the calling routine at1295.
• FIG. 13 is a flowchart showing steps taken to perform particular functions, including handling application logon processing. Processing commences at1300 whereupon a determination is made as to whether a gadget (application) password is being requested (seeFIG. 7 for an example of an application password dialog). As previously described, when application authentication is needed (e.g., to access the user's email account, etc.), thendecision1305 branches to the “yes” branch whereupon steps1315 to1355 are performed to handle the application authentication process. These steps communicate with the particular gadget (application)1310. Atstep1315, authentication requirements (e.g., name, password, etc.) are retrieved from selectedapplication1310. At step1320, an authentication input dialog is built based on the authentication requirements provided by the selected application or the authentication dialog is provided by the selected gadget. At step1325, the window (e.g.,410 in eitherFIG. 4 or5, etc.) visually appears to “flip” to show the window's backside where the authentication input dialog is displayed to the user (seeFIG. 7,window700, for an example of the authentication input dialog). At step1330, the requested authentication data (e.g., name, password, etc.) is received from the user via the displayed authentication input dialog. Atstep1335, the received data is provided to selectedapplication1310 for processing. The selected application returns a response indicating whether the user's authentication data was successfully authenticated (decision1340). If the user was successfully authenticated, then decision1340 branches to the “yes” branch whereupon, at step1345, the application window appears to visually “flip” back over to reveal the unlocked application (e.g., the user's email application with email messages being visible and readable, etc.). On the other hand, if the user was not successfully authenticated, then decision1340 branches to the “no” branch whereupon, atstep1350, an appropriate error message is displayed to the user. Processing then returns to the calling routine at1355.
• Returning todecision1305, if the request was not for input of application authentication data, thendecision1305 branches to the “no” branch whereupon a determination is made as to whether the request is to scroll through open windows (e.g., using horizontal scrolling controls450 and460 inFIG. 4 or vertical scrolling controls550 and560 shown inFIG. 5) atdecision1360. If the request is to scroll through open windows, thendecision1360 branches to the “yes” branch whereupon a determination is made as to which direction the user is requesting to scroll (decision1365). If a horizontal scroll is being requested, thendecision1365 branches to the horizontal scroll branch whereupon the area of scrollable windows is scrolled horizontally left or right as requested by user selection of left or right arrows. When the beginning or end of window list reached, the scrolling wraps to end or beginning, respectively. On the other hand, if a vertical scroll is being requested, thendecision1365 branches to the vertical scroll branch whereupon the area of scrollable windows is scrolled up or down as requested by the user's selection of the up or down arrows. When the beginning or the end of the window list reached, scrolling wraps to the end or the beginning of the list, respectively. Processing then returns to the calling routine at1380.
• Returning todecision1360, if the request is not to scroll through open windows, thendecision1360 branches to the “no” branch whereupon a determination is made as to whether to scroll through the icon ribbon bar (decision1384). If the request is to scroll through the icon ribbon bar, thendecision1384 branches to the “yes” branch whereupon, at step1388, scroll of icons corresponding to available applications is performed left or right as requested by user using the left or right arrow GUI controls. When the beginning or the end of the list of available applications reached, the display wraps to display the end or the beginning of list, respectively. On the other hand, if the request is not to scroll through icons displayed in the icon ribbon bar, thendecision1384 branches to the “no” branch whereupon the function requested by the user is performed. Processing then returns to the calling routine at1395.
• FIG. 14 is a diagram showing a mixed mode display screen with user management functionality of the vertically scrollable window area. When the user requests to manage the vertically scrollable window area by selecting GUI control555 (seeFIG. 5), then vertical scrollablewindow management display1400 is displayed in the area where the vertically scrollable window area is normally seen (seeFIG. 5). Vertical scrollablewindow management display1400 includesvisible application list1410 andcatalog1450 of other applications. The visible application list includesapplications1440 andcatalog1450 includesapplications1460. To remove an application from the visible application list, the user selects the minus sign (−) icon displayed to the right of the selected application's name in the list. Likewise, to move an application from the catalog to the visible application list, the user selects the plus sign (+) icon displayed to the right of the desired application's name in the catalog. GUI controls1470 and1480 are used to scroll up and down, respectively, through the catalog. In addition, GUI controls1420 and1430 are used by the user to select how much width the vertically scrollable window area occupies. WhenGUI control1420 is selected, the width of the windows in the vertically scrollable window is increased and the width oflarge window510 is decreased by approximately the same amount. Likewise, whenGUI control1430 is selected, the width of the windows in the vertically scrollable window is decreased and the width oflarge window510 is increased by approximately the same amount.
• One of the implementations of the invention is a client application, namely, a set of instructions (program code) or other functional descriptive material in a code module that may, for example, be resident in the random access memory of the computer. Until required by the computer, the set of instructions may be stored in another computer memory, for example, in a hard disk drive, or in a removable memory such as an optical disk (for eventual use in a CD ROM) or floppy disk (for eventual use in a floppy disk drive). Thus, the present invention may be implemented as a computer program product for use in a computer. In addition, although the various methods described are conveniently implemented in a general purpose computer selectively activated or reconfigured by software, one of ordinary skill in the art would also recognize that such methods may be carried out in hardware, in firmware, or in more specialized apparatus constructed to perform the required method steps. Functional descriptive material is information that imparts functionality to a machine. Functional descriptive material includes, but is not limited to, computer programs, instructions, rules, facts, definitions of computable functions, objects, and data structures.
• While particular embodiments of the present invention have been shown and described, it will be obvious to those skilled in the art that, based upon the teachings herein, that changes and modifications may be made without departing from this invention and its broader aspects. Therefore, the appended claims are to encompass within their scope all such changes and modifications as are within the true spirit and scope of this invention. Furthermore, it is to be understood that the invention is solely defined by the appended claims. It will be understood by those with skill in the art that if a specific number of an introduced claim element is intended, such intent will be explicitly recited in the claim, and in the absence of such recitation no such limitation is present. For non-limiting example, as an aid to understanding, the following appended claims contain usage of the introductory phrases “at least one” and “one or more” to introduce claim elements. However, the use of such phrases should not be construed to imply that the introduction of a claim element by the indefinite articles “a” or “an” limits any particular claim containing such introduced claim element to inventions containing only one such element, even when the same claim includes the introductory phrases “one or more” or “at least one” and indefinite articles such as “a” or “an”; the same holds true for the use in the claims of definite articles.
Additional Notes:
• In addition, we have another view called Cinema view—this is specifically for viewing movies. When the User is in Cinema Mode, the Top Bar is hidden, all radios are turned off and all notifications are stopped. The idea of this is for viewing Movies and Television on both the Apollo display which supports 720p High Definition video playback and on an external monitor or HD Television. The thought is that Users really want to get a full TV like media experience in this mode. There is an Expand Button that exists in the Media Controls of the Media Apps (Photos, Music and Video). In build today. There is also a Control called a Snap Bar that exists in 3 Space Mode. The Snap Bar is a “grab handle” that exists between the primary Application area in 3 Space mode and the Gadgets on the Right side of the screen. When the User moves the Grab Handle Left or Right, the primary application area Snap's to a new width. There is a Keyboard Control that allows the User to press a keyboard combination to move to Full Screen and Cinema Mode. To return they can press the Esc key. The Snap Bar allows the User to move between three different views:Standard 3 Space Mode: When an application is opened by Clicking on the Gadget in 6 Space or 3 Space mode, the default size that it opens to is the area you see in the attached Mock Ups. This size is 1024 Pixels wide (not including the scroll bar). We selected this width specifically since most Web Sites today are optimized for the 1024 width screens. This will be a very unique feature in this platform since on a standard 1024 width computer—the Vertical Scroll Bar takes horizontal space which forces the User to have a Horizontal Scroll Bar which reduces the available viewing area. With the Fusion/Apollo design, the default width of the App when it opens is 1024+17 Pixels. The 17 Pixels is the Width of our Vertical Scroll bar. Our goal is to vastly reduce the chance of the User having wasted space used by this horizontal scroll bar. If needed we have wireframe drawings that show the exact dimensions of each area of the screen (Top Bar, Shuttle Bar, 6 Space Gadgets, 3 Space Narrow Gadgets, 3 Space Wide Gadgets, etc). Wide Gadget View: this Snap position will make the Gadgets exactly the same size and width as the 6 Space Gadgets. To move to this position, the User drags the Snap Bar left a small distance, when the let go of the grab handle with the pointer, the GUI snaps to the next position. The reasoning behind this is to allow Users to have larger Gadgets next to the working area where they may have a browser or other application such as Google Docs, Open Office or other Application. The larger Gadget size allows for more content in the viewable area of the Gadget as well as the ability to do more exciting feature like viewing a Movie the Gadget while they are surfing the Internet, doing Email or working on other tasks like Document editing/creation. Movies will play in the Video Gadget when it's in Narrow mode but are harder to see and become very small since this isn't the proper aspect ratio for most modern movies. Full Screen View: This is invoked when the User moves the Grab Handle from the Standard Width position to the Right a small distance. When this is done, the GUI goes to Full Screen Mode Cinema Mode: The User can move to Cinema mode by pressing the Media Player control that expands the screen. Direct to Cinema Mode Control: This feature isn't currently implemented but is planned for the first release. The idea is to have a control that is either on the Top Bar of the Multimedia Gadgets or within the Viewing area of these same gadgets (Final decision on location pending technical assessment). When the User presses this control, they will move from the Gadget view directly to Cinema View enabling a quick playback feature for movies as well as other media (Photo Screenshow, Music Playback). To return from these modes, the User can use: The Esc key to return from Cinema Mode and Full Screen to the previous state The Top Bar ICONs to return to 3 Space or 6 Space view directly. To Shutdown or Reboot the system, the User can: Press the Power Button: when pressed, they are presented with a Dialog Box (Shutdown, Reboot, Cancel). If they take no action, the default is to Shutdown, this will happen after a 60 second countdown delay. There will be a countdown timer on the screen. Click on the Apollo (code name) ICON on the top left of the Top Bar. This provides a drop down menu that allows the User to select Shutdown or Reboot directly from the menu. There are multiple focus concepts in the design Gadget Focus: when a User clicks anywhere in a gadget Top Bar, Bottom Bar or in the active area of the Window, the Gadget get's focus. When the Gadget has focus, the Screen Region Focus: The User will be able to select areas on the screen that would provide focus for the entire “region.” Since this GUI isn't a traditional Single Document Interface (SDI) or Multiple Document Interface (MDI), we needed a method to provide Users control of regions of the screen so they can easily navigate, scroll, switch views, etc. For example: 3 Space Side Region Focus: There is a small Top Bar (similar to a title bar but with different functions) that exists in the 3 Space Region of the GUI. If the User clicks anywhere on this bar or on any button on this bar, they will have selected the entire region of the screen which will then have Focus Focus is indicated by a Blue Glow—see Focus Indicator description below. When this region has focus, the Touchpad, Mouse and Keyboard can be used to navigate within this region of the screen independently from other regions of the screen (such as Applications and Gadgets). The 3 Space Gadgets scroll up and down on the screen, independently from the 3 Space Application Region. In addition, each gadget supports the concept of scrolling within the gadget when needed. 3 Space Application Region Focus: when the Application Area has focus, the User can use Keyboard and Mouse controls to easily scroll between applications. Applications stay open if the User opens a second Application but are non-visible to either the Left or Right side of the visible window. To navigate between Application Windows the User can: Use the Ribbon Bar: The Ribbon Bar is used to quickly navigate between open applications. The Ribbon Bar is unique in the Fusion/Apollo user interface since it provides navigation in multiple directions. The User can Navigate Left or Right in the open Applications In addition, the User can navigate directly to a nested instance of the Application. If an application has more than one instance opened the Ribbon bar will show up with a single (most recently used instance) view of the application in the Ribbon Left/Right string. The applications are shown as small screen images of the running application. If this application has other instances running—(such as the Multimedia Apps, Music, Video, Photos or Documents), then if the User hovers over the picture of the application image, a pop-up will slide up and show the User pictures of each of the running instances that reflect the current state of those applications. The ribbon bar is invoked multiple ways: If the pointer is held at the bottom of the screen for a pre-determined period (currently 225 ms—tuning in process), the Application Bar slides into place (final animation under development). There is also a keyboard control that allows navigation to the Ribbon bar. The final key combinations are being tested but the following is a representative example:
• The User presses Ctrl+Tab or Alt+Tab—the Ribbon Bar slides into place The Ribbon Bar now has focus The User can move between applications using the Tab key on the keyboard. If the User presses Enter, that application Fades into view (Fade is an animation that would fade the currently visible application into the background and then fade the requested application into view. If the User Tabs to a new application and that application has multiple instances running, the pictures of those instances slide into view and if the User waits a small amount of time, the Tab Key will allow navigation between those applications as well. When the User reaches the end of the nested application list, pressing Tab will move to the next Application in the Ribbon Bar. If the last Application is reached, the next press of the Tab key will loop back to the first Application in the Ist. Focus Indicator: There will be a visual indicator when a Gadget or Area has “focus”. The current design is a Blue Glow effect that indicates that this region of the screen or this specific Gadget or Application has Focus. Quick Notify/Quick Reply feature: Some other unique features of our GUI include the way we Notify users of incoming events and then allow them to take actions that are high value without having to open an application or Gadget directly. For example, if you look at the SMS Charts I've attached, you will see the SMS Quick Text concept in action. A new TXT (SMS or MMS) message arrives The Top Bar ICON Flashes and a Sound notifies the User of the incoming TXT A notification area slides into view. The User can take direction action from this notification area (rather than having to open the full function GUI as is traditionally used in IM/TXT type applications. For example, the User can press the Reply Button in the notification area and quickly read the TXT and then reply to that TXT without opening the full SMS Application. This concept will be used in the Instant Messaging tools that are being developed as well for Apollo/Fusion. This will include a Chat tool and a VoIP tool. A unique feature of the Fusion GUI design is the way we have tied in communication and control functions between gadgets and applications. For example, the User can start the playback of a video in the Video gadget and then decide to move to another task. To continue watching the Video, all they need is for the Video gadget to be in the visible area. This not only allows them to see video playing in the gadget but also allows direct manipulation of the Video controls. To do this, we have set up a communications pipe between gadgets and Apps. Another example is applications like Mail—our gadget allows the User to directly manipulate the content in the browser. An example, would be reading/editing/management of mail. The User can bring the Side Space gadget into view simultaneously with the browser. In the browser, they can see the current email. In the Gadget, they can see a list of all emails. They can take action in the Gadget and see that action directly reflected in the Application. For example, they could move to the next mail with far fewer clicks since they don't have to navigate in the browser (1 click, vs 3) or they could do tasks like deleting or composing new mail by a single click in the Gadget. There will be a Chat ICON for Instant Messaging and an SMS ICON for SMS Text. There will also be a language ICON that allows the User to quickly change language settings if they are using a language that could required mixed keyboard support like Chinese.

Claims (21)

1. A machine-implemented method comprising:

receiving a selection of a first displayed window from a plurality of displayed windows visible on a display, wherein the first displayed window corresponds to a first software application and wherein the first displayed window is displayed at a first location on the display;

visually animating a second displayed window forming from the first displayed window;

displaying an authentication input dialog on the second displayed window, wherein the displayed authentication input dialog corresponds to the first software application;

receiving authentication data at the authentication input dialog; and

authenticating the received authentication data.

2. The method ofclaim 1 further comprising:

retrieving one or more authentication requirements from a software gadget corresponding to the first displayed window; and

generating the authentication input dialog based on the retrieved authentication requirements.

3. The method ofclaim 1 wherein the authenticating further comprises:

sending the received authentication data to a software gadget corresponding to the first displayed window; and

receiving a response from the software gadget that indicates whether the received authentication data was successfully authenticated.

4. The method ofclaim 1 wherein the first displayed window is one of a plurality of medium-sized windows displayed in a grid format on the display, wherein each of the medium-sized windows has a substantially common width and a substantially common height.

5. The method ofclaim 1 further comprising:

closing the second displayed window and returning focus to the first displayed window in response to the authenticating being successful.

6. The method ofclaim 1 further comprising:

inverting one or more display characteristics from the first displayed window to the authentication input dialog that distinguishes the authentication input dialog from the other windows included in the plurality of displayed windows.

7. The method ofclaim 1 wherein the second displayed window is displayed at a common screen position to the first displayed window so that when the second displayed window appears the first displayed window is not visible on the screen.

8. A computer program product in a computer-readable storage medium comprising functional descriptive material that, when executed by a computer, directs the computer to perform actions comprising:

receiving a selection of a first displayed window from a plurality of displayed windows visible on a display, wherein the first displayed window corresponds to a first software application and wherein the first displayed window is displayed at a first location on the display;

visually animating a second displayed window forming from the first displayed window;

displaying an authentication input dialog on the second displayed window, wherein the displayed authentication input dialog corresponds to the first software application;

receiving authentication data at the authentication input dialog; and

authenticating the received authentication data.

9. The computer program product ofclaim 8 wherein the computer program product directs the computer to perform additional actions comprising:

retrieving one or more authentication requirements from a software gadget corresponding to the first displayed window; and

generating the authentication input dialog based on the retrieved authentication requirements.

10. The computer program product ofclaim 8 wherein the authenticating further comprises:

sending the received authentication data to a software gadget corresponding to the first displayed window; and

receiving a response from the software gadget that indicates whether the received authentication data was successfully authenticated.

11. The computer program product ofclaim 8 wherein the first displayed window is one of a plurality of medium-sized windows displayed in a grid format on the display, wherein each of the medium-sized windows has a substantially common width and a substantially common height.

12. The computer program product ofclaim 8 wherein the computer program product directs the computer to perform additional actions comprising:

closing the second displayed window and returning focus to the first displayed window in response to the authenticating being successful.

13. The computer program product ofclaim 8 wherein the computer program product directs the computer to perform additional actions comprising:

inverting one or more display characteristics from the first displayed window to the authentication input dialog that distinguishes the authentication input dialog from the other windows included in the plurality of displayed windows.

14. The computer program product ofclaim 8 wherein the second displayed window is displayed at a common screen position to the first displayed window so that when the second displayed window appears the first displayed window is not visible on the screen.

15. An information handling system comprising:

one or more processors;

a memory accessible by at least one of the processors;

a display accessible by at least one of the processors; and

a set of instructions stored in the memory, wherein the one or more processors executes the set of instructions to perform actions of:

receiving a selection of a first displayed window from a plurality of displayed windows visible on a display, wherein the first displayed window corresponds to a first software application and wherein the first displayed window is displayed at a first location on the display;

visually animating a second displayed window forming from the first displayed window;

displaying an authentication input dialog on the second displayed window, wherein the displayed authentication input dialog corresponds to the first software application;

receiving authentication data at the authentication input dialog; and

authenticating the received authentication data.

16. The information handling system ofclaim 15 wherein the set of instructions performs additional actions comprising:

retrieving one or more authentication requirements from a software gadget corresponding to the first displayed window; and

generating the authentication input dialog based on the retrieved authentication requirements.

17. The information handling system ofclaim 15 wherein the authenticating further comprises actions of:

sending the received authentication data to a software gadget corresponding to the first displayed window; and

receiving a response from the software gadget that indicates whether the received authentication data was successfully authenticated.

18. The information handling system ofclaim 15 wherein the first displayed window is one of a plurality of medium-sized windows displayed in a grid format on the display, wherein each of the medium-sized windows has a substantially common width and a substantially common height.

19. The information handling system ofclaim 15 wherein the set of instructions performs additional actions comprising:

closing the second displayed window and returning focus to the first displayed window in response to the authenticating being successful.

20. The information handling system ofclaim 15 wherein the set of instructions performs additional actions comprising:

inverting one or more display characteristics from the first displayed window to the authentication input dialog that distinguishes the authentication input dialog from the other windows included in the plurality of displayed windows.

21. The information handling system ofclaim 15 wherein the second displayed window is displayed at a common screen position to the first displayed window so that when the second displayed window appears the first displayed window is not visible on the screen.

Images