The present patent disclosure relates generally to graphical user interfaces, and in particular to a system and method of navigating graphical user interface elements.
Devices with a graphical user interface display visual elements. The visual elements can be navigated using an input device. The visual elements may be, for example, icons representing programs. The visual elements may have a focused and unfocused state, indicating which visual element is currently selected, and thus further inputs relate to, such as for example, starting the program represented by a focused icon.
The input devices may allow for input control in multiple dimensions. For example, a scroll wheel provides input control in one dimension, such as for example, up/down or left/right. A track ball, or mouse may provide input control in two dimensions, such as in both the x and y directions. The input device may control what visual element has focus. For example, in graphical user interface with a pointer, the input device controls the position of the pointer on the GUI, and the visual element located under the pointer may have the focus. In GUIs that do not use a pointer, the input device may control the visual elements that have the focus by scrolling through the visual element. For example, the visual elements may be assigned a navigation order, and the focus is determined based on the visual element that currently has the focus using the input and the navigation order.
It is often difficult to quickly scroll through visual elements and stop immediately on the desired visual element. For example, the desired visual element may be passed and have to be returned to.
Embodiments of the system and method for navigating among visual elements of a graphical user interface will now be described by way of example with reference to the following drawings in which:
a-d show in block diagrams, exemplary illustrations of graphical user interfaces (GUI), in accordance with an illustrative embodiment of the system for navigating among visual elements;
a-b depict in exemplary block diagrams, the logical components of illustrative embodiments of environments for navigating among visual elements;
In accordance with the present disclosure there is provided a system for navigating a graphical user interface comprising a plurality of visual elements. The system comprises an input component for receiving an input and generating a navigational input based on the input, a visual element analyzer for analyzing visual elements to determine if the visual elements have an associated blockade condition, and for passing navigational inputs. The system further comprises a blockade condition analyzer for analyzing visual elements with an associated blockade to determine if the navigational input satisfies the blockade condition and an output component for receiving the navigational inputs passed from the visual element analyzer and for generating the input based on the navigational input.
In accordance with the present disclosure there is further provided a method of navigating a graphical user interface comprising a plurality of visual elements. The method comprises the steps of receiving an input and generating a navigational input based on the input, analyzing visual elements to determine if the visual elements have an associated blockade condition, generating the input based on the navigational input if the visual elements don't have an associated blockade condition, analyzing visual elements with an associated blockade to determine if the navigational input satisfies the blockade condition, and generating the input based on the navigational input if the blockade condition is satisfied.
In accordance with another embodiment of the present disclosure, there is provided a computer program product for navigating a graphical user interface comprising a plurality of visual elements. The computer program product comprises a computer readable medium embodying program code means for implementing a method of navigating the graphical user interface. The method comprises the steps of receiving an input and generating a navigational input based on the input, analyzing visual elements to determine if the visual elements have an associated blockade condition, generating the input based on the navigational input if the visual elements don't have an associated blockade condition, analyzing visual elements with an associated blockade to determine if the navigational input satisfies the blockade condition, and generating the input based on the navigational input if the blockade condition is satisfied.
In accordance with a further embodiment of the present disclosure, there is provided a propagated signal carrier carrying signals containing computer-executable instructions that can be read and executed by a computer, the computer-executable instructions being used to execute a method of navigating a graphical user interface comprising a plurality of visual elements. The method comprises the steps of receiving an input and generating a navigational input based on the input, analyzing visual elements to determine if the visual elements have an associated blockade condition, generating the input based on the navigational input if the visual elements don't have an associated blockade condition, analyzing visual elements with an associated blockade to determine if the navigational input satisfies the blockade condition, and generating the input based on the navigational input if the blockade condition is satisfied.
The system and method of navigating graphical user interface elements provides the ability to specify a condition to be met prior to navigating away from a current visual element. For example, if the visual elements are icons for a program, a blockade condition may be set on a particular icon. When the icon is navigated to, the blockade condition is checked and if it is satisfied, the navigation is blocked at the particular icon until navigational inputs no longer satisfy the blockade condition. By blocking the navigation at a particular icon, it is possible to quickly and easily navigate to the particular icons.
A system and method of the present patent disclosure will now be described with reference to various examples of how the embodiments can best be made and used. For convenience, like reference numerals are used throughout the description and several views of the drawings to indicate like or corresponding parts, wherein the various elements are not necessarily drawn to scale.
a-d show in block diagrams exemplary illustrations of graphical user interfaces (GUI) 101, in accordance with the present application. The GUI 101 comprises a plurality of visual elements 105a-105d. The visual elements 105a-105b may be in an unfocused state or in a focused state. The focused state is represented schematically by box 110a-110b.
The visual elements may be navigated among. The navigation among the visual elements 105a-d may occur in a specific navigation order. The order may be a one dimensional (1D) order. If the navigation order is 1D, then navigation among the visual elements would progress, for example, from
The specific navigation order may also be a two dimensional order (2D). A 2D order allows for additional visual elements to be navigated to from the currently focused visual element. For example, from
For the sake of clarity of the description the visual elements 105a-d will be referred to generally as 105. A visual element 105 that is in a focused state 110a-d will be referred to generally as 110.
For the sake of clarity of the description the environment 200a,b will be referred to generally as 200. An operating system 205a,b will be referred to generally as 205. Blockade logic 210a,b will be referred to generally as 210. An application 215a,b will be referred to generally as 215.
The navigation among the visual elements 105 may be controlled by the input device 305. The input device 305 provides navigational inputs for controlling the navigation among the visual elements 105. The navigational inputs may comprise information regarding the navigation direction. For example in 1D it may be representative of left/right or up/down. In a 2D navigation order, the direction may comprise information regarding movement in the two dimensions, for example, x and y coordinates indicating movement amount and direction of movement in each dimension. The navigational inputs may also comprise information regarding a time that the navigational inputs occurred.
The navigational order may be provided in various ways. The visual elements 105 may be represented by objects, each of the object indicating a previous and next visual element 105 in the navigation order. If the navigation order is 2D, the objects may further include third and fourth visual element for indicating the next and previous visual elements in the additional direction. Alternatively the navigation order may be specified in a separate structure such as a file or navigation object.
For the sake of clarity and without the loss of generality, the blockade conditions represented by 415a-d will be referred to as blockade condition 415, and the visual element navigation indication 410a-d will be referred to as 410.
A blockade may be placed on a visual element 105. A blockade on a visual element 105 includes a blockade condition 405. In order to navigate from a blocked visual element 105 (that is a visual that comprises a blockaded condition) in the focused state 110 to another visual element specified in the navigation order, for example by the visual element navigation indication 410, the blockade condition 415 must be met. If the blockade condition 415 is met then the navigation input is passed onto applications 215 as may normally occur. If the blockade condition 415 is not met, the navigation input is dropped. As a result of the navigational input being dropped the navigation input may not be received by an application 215, and from the point of view of the application 215, the navigation input did not occur.
The blockade condition 415 may be specified in various manners depending on the requirement of the GUI 101. For example, a blockade condition 415 may indicate a blockade time. The blockade time may indicate, for example, a minimum time period that must pass between when a visual element 105 is navigated to and when it can be navigated from. Alternatively, the blockade condition 415 may indicate a number of navigational inputs that must occur between when a visual element 105 is navigated to and when it can be navigated from. A complex blockade condition may be a combination of various blockade conditions 415. For example, a complex blockade condition may indicate that 4 navigational inputs must be received or 3 seconds must have passed before the visual element 105 may be navigated from.
The blockade conditions 415 may be created in various ways. For example, the visual elements 105 may be represented by objects, which include blockade condition 415 information. A single blockade condition 415 may be specified for each visual element 105. Alternatively or additionally, multiple blockade conditions 415 may be specified. The multiple blockade conditions 415 may be required to be met depending on the direction of navigation. For example, in a 1D navigation order, different blockade conditions 415 may be created for navigating to the next visual element 410 or the previous visual element 410. If the order is multidimensional, various blockade conditions 415 may be created for navigation in the different directions to the appropriate visual element 410.
Alternatively or additionally to including the blockade condition 415 with a visual element object 400, the blockade conditions 415 may be stored in a separate structure such as a file, or blockade condition object.
In determining if a blockade condition 415 has been met, the blockade logic 315 may require additional information. For example, if the blockade condition 415 specifies a navigation time, the blockade logic 315 requires information about the time at which the current visual element 105 was navigated to. This information may be stored when the current navigation element is updated to the next navigation element. If the blockade condition 415 specifies the number of navigational inputs to drop prior to navigating to the next navigation element, then the blockade logic 315 may require information about how many navigational inputs have been dropped since the current navigational element was navigated to.
The handheld device 600 includes a display 610. The display 610 displays a GUI 101 that includes a plurality of visual elements 620. The visual elements 620 may be, for example, icons for selecting an application to run. Icon 620D is shown as being the current navigation object. Icon 620G is a blocked icon. The blockade condition of icon 620G specifies that 3 navigation inputs should be dropped when navigating to the right, and no blockade condition is specified for navigating to the left.
A navigation input may navigate from the current navigation element to the next navigation element specified by the specific 1D navigation order, assuming no blockade conditions or the blockade conditions are met. For example a navigation input of ‘down’, navigates from the current icon 620D to the next icon 620E on the right (or on the far left of the next row if it is the last icon of a row). A navigation input of ‘up’, navigates from the current icon 620D to the next icon 620C on the left (or on the far right of the previous row if it is the first icon of the previous row)
The specific 1D navigation order is 620A⇄620B⇄620C⇄620D⇄620E⇄620F⇄620G [blockaded]⇄620H⇄620I⇄620J⇄620K⇄620L. This specific 1D navigation order does not provide for looping navigation, for example from 620A to and from 620L.
When a new navigation input is received, the navigation direction is determined. For example, when the scroll wheel 605 is scrolled down 1 click, the navigation direction is determined as to the right, and when it is scrolled up 1 click the navigation direction is determined as to the left. Using the navigation input navigation direction, the next navigation element is determined. For example, when a navigation direction of right is received when the icon 620D is in focus as shown, the next navigation element is determined as 620E. Once the navigation direction is determined, it is determined if there is a blockade condition on navigating from the current visual element 620D in that direction. For example the navigation direction is determined as ‘right’. Since 620D does not have a blockade condition, the navigation input is passed, for example to the device operating system, resulting in the current navigation element being changed to icon 620E. Having navigated to icon 620E, it would be in the focused state, and icon 620D would be in the unfocused state. Another navigation input may be received indicating a navigation direction of ‘right’ again. Since no blockade condition exists on icon 620E, icon 620F is navigated to, making icon 620F in focus and 620E unfocused. Another navigation input may be received indicating a navigation direction of ‘right’ again. Since no blockade condition exists on icon 620F, icon 620G is navigated to, making icon 620G in focus and 620F unfocused. Another navigation input may be received indicating ‘right’ as the navigation direction again. However icon 620G has a blockade condition when navigating to the right from icon 620G, indicating that 3 navigation inputs should be dropped prior to navigating from. As a result the navigation input is dropped (1 dropped navigation input of 3). Another navigation input may be received indicating ‘right’ as the navigation direction again, and again the blockade condition will not have been met so the navigation input is dropped (2 of 3). Another navigation input may be received indicating ‘right’ as the navigation direction again, and again the blockade condition will not have been met so the navigation input is dropped (3 of 3). Another navigation input may be received indicating ‘right’ as the navigation direction again, however now the blockade condition is met, and so the navigation input is passed, allowing navigation from icon 620G to icon 620H. Icon 620H would then be in the focused state, and icon 620G would be in the unfocused state.
A navigation input may then be received indicating ‘left’ as the navigation direction. Since icon 620H does not have a blockade condition, icon 620G would be navigated to. Another navigation input may be received indicating ‘left’ as the navigation direction. As described above, icon 620G does not have a blockade condition for navigating from the icon 620G to the left, and so the navigation input is passed, and icon 620F is navigated to.
Although it may be desirable to have the navigation order correspond to the relative location of the visual elements as displayed by the GUI, it is not required to do so. From the above example described with reference to
The scroll wheel of the above description may be replaced or augmented with other input devices, such as for example. a thumbwheel, a joystick, or a combination of keys such as the up and down arrows on a keyboard. The input devices are well suited for providing navigation control in 1D, it is understood that many different 2D input devices could be used, such as a mouse, trackball, touchpad, thumb pointer or scroll ball may also be used to control navigation in 1D by ignoring or not using direction information from one of the dimensions.
The handheld device 700 includes a display 610. The display 610 displays a GUI 101 that includes a plurality of visual elements 720. The visual elements 720 may be, for example, icons for selecting an application to run. Icon 720D is shown as being the current navigation object. Icon 720G is a blocked icon. The blockade condition of icon 720G is similar to that of 620G. It specifies that 3 navigation inputs should be dropped when navigating to the right, and no blockade condition is specified for navigating to the left. However, since the specific navigation order is 2D, the blocked visual element 720G may further describe blockade conditions for the additional navigation directions.
A navigation input may navigate from the current navigation element to the next navigation element specified by the specific 2D navigation order, assuming no blockade conditions or the blockade conditions are met. For example a navigation input of ‘down’, navigates from the current icon 720D to the icon in the row below, icon 720H. A navigation input of ‘up’, does not result in any navigation since the icon 720D is in the top row. As described above, if looping navigation was used, a navigation input of ‘up’ could result in navigating to visual element 720L. A navigation input of ‘left’ navigates from the current icon 720D to icon 720C. A navigation input of ‘right’ does not result in any navigation since the icon 720D is in the far right row. If looping navigation was used, a navigation input of right, could result in a navigation to icon 720A.
A specific 2D navigation order is specified. As described above, the specific 2D navigation order may be specified in various ways. The specific 2D navigation order should generally specify 4 visual elements that may be navigated to from a current visual element. Each visual element does not require to have all 4 navigation elements described. Examples of the specific 2D navigation order are described below, with square brackets indicating a blockade condition.
The operation of the device 700 is similar to that of device 600. When a navigation input is received, the direction is determined, the navigation order is checked to see if the visual element of the current navigation element has a blockade condition in that direction, and if it does the blockade condition is checked to see if it has been satisfied. However, the device 700 may allow navigation to more than two visual elements, and each navigation to the visual elements may have a blockade condition.
As depicted in
Blockade conditions may be set for the various visual elements. In an illustrative embodiment of setting blockade conditions, an application may be used to setup the blockade conditions. The application may display the visual elements of a GUI, and allow a user to specify a blockade condition. This may be done through a series of wizards or prompts. For example, the blockade setting application may present an interface that allows a visual element to be selected. A prompt may be presented that provides for the specification of the blockade condition. A first prompt may specify the navigation direction the blockade condition is associated with. The first prompt may provide for specifying that the same blockade condition be used for all navigation directions, or providing for individual navigation directions to be selected. Once the navigation direction is selected, a second prompt may be generated for allowing the blockade condition to be specified. The second prompt may for example allow for specifying the number of dropped navigation inputs, a minimum elapsed time before allowing navigation, or a minimum movement amount of the input in the navigation direction. Once the blockade condition is set, the blockade setting application may allow for testing the blockades that have been set. The blockade setting application may display the GUI with the visual elements, and newly set blockade conditions. The application provides for navigating among the visual elements. A user may use this to determine if the blockade conditions are appropriate. The blockade setting application may exit the blockade testing mode by a specific input, for example pressing a key on the device. After exiting the testing mode, the blockade setting application may present a prompt for selecting whether to accept the blockades or to modify the blockades. Once the blockade conditions are accepted, the blockade setting application may modify or create the blockade structures for implementing the newly created or modified blockade conditions.
Additionally or alternatively, the device may be provided with other options of creating or modifying blockade conditions. For example an alternative input, for example a right click on a mouse or pressing shift enter on a keypad, may be used to present a menu for modifying or creating a blockade condition on an individual visual element.
Additionally or alternatively, the device may automatically set blockade conditions. For example, the amount of times a specific visual element is selected may be monitored. If this amount crosses a threshold, a blockade condition may automatically be set for the specific visual element.
Additionally or alternatively, the visual elements of the GUI may be grouped into categories. For example, the visual elements 720 may be grouped into vertical groups. So that visual elements 720A,E,I are in a group; 720B,F,J are in a group; 720C,G,K are in a group; and 720D,H,L are in a group. The blockade may then be set for the group of visual elements.
The visual element analyzer component 910 may store the current visual element in a navigation order. If the visual element analyzer component 910 determines that the next visual element should be navigated to, the current visual element stored by the visual element analyzer component 910 can be updated. The current visual element may be used by the blockade condition analyzer component 915 to determine whether the blockade condition has been met.
The blockade condition analyzer component 915 may receive the current navigational input as well as the current visual element. The blockade condition analyzer component 915 may store the current visual element in a visual element table. When a visual element is analyzed to determine if its blockade condition has been satisfied, the blockade condition analyzer component 915 may check the visual element table to determine if it is currently in the table. If the visual element is not found in the table, a new entry may be added. The table entry may include a visual element identifier to uniquely identify each visual element, as well as the current blockade condition state. Once the visual element entry is found, or created, the blockade condition analyzer component 915 updates the blockade condition state of the table entry according to the navigation input. The blockade condition analyzer component 915 then determines if the blockade condition state of the visual element table entry meets the blockade condition associated with the navigational direction of the visual element. The result of the determination is then returned to the visual element analyzer component, which may send the appropriate navigational input to the output component 920.
The blockade condition analyzer component 915 may receive a visual element when determining if the blockade condition has been met. Alternatively the blockade condition analyzer component 915 may be incorporated into the visual element analyzer component 910 or as part of the visual element objects (see
Handheld device 1002 will normally incorporate a communication subsystem 1011, which includes a receiver 1012, a transmitter 1014, and associated components, such as one or more (preferably embedded or internal) antenna elements 1016 and 1018, local oscillators (LOs) 1013, and a processing module such as a digital signal processor (DSP) 1020. As will be apparent to those skilled in the field of communications, particular design of communication subsystem 1011 depends on the communication network in which handheld device 1002 is intended to operate.
Handheld device 1002 may send and receive communication signals over the network after required network registration or activation procedures have been completed. Signals received by antenna 1016 through the network are input to receiver 1012, which may perform such common receiver functions as signal amplification, frequency down conversion, filtering, channel selection, and analog-to-digital (A/D) conversion. A/D conversion of a received signal allows more complex communication functions such as demodulation and decoding to be performed in DSP 1020. In a similar manner, signals to be transmitted are processed, including modulation and encoding, for example, by DSP 1020. These DSP-processed signals are input to transmitter 1014 for digital-to-analog (D/A) conversion, frequency up conversion, filtering, amplification and transmission over communication network via antenna 1018. DSP 1020 not only processes communication signals, but also provides for receiver and transmitter control. For example, the gains applied to communication signals in receiver 1012 and transmitter 1014 may be adaptively controlled through automatic gain control algorithms implemented in DSP 1020.
Network access is associated with a subscriber or user of handheld device 1002, and therefore handheld device 1002 comprises a memory module 1062, memory module card or a Removable User Identity Module (RUIM), to be inserted in or connected to an interface 1064 in order to operate in the network. Alternatively, memory module 1062 may be a non-volatile memory that is programmed with configuration data by a service provider so that mobile station 1002 may operate in the network. Since handheld device 1002 is a mobile battery-powered device, it also includes a battery interface 1054 for receiving one or more rechargeable batteries 1056. Such a battery 1056 provides electrical power to most if not all electrical circuitry in handheld device 1002, and battery interface 1054 provides for a mechanical and electrical connection for it. The battery interface 1054 is coupled to a regulator that provides power V+ to all of the circuitry.
Handheld device 1002 includes a microprocessor 1038 that controls overall operation of mobile station 1002. Communication functions, including at least data and voice communications, are performed through communication subsystem 1011. Microprocessor 1038 also interacts with additional device subsystems such as a display 1022, a flash memory 1024, a random access memory (RAM) 1026, auxiliary input/output (I/O) subsystems 1028, a serial port 1030, a keyboard 1032, a speaker 1034, a microphone 1036, a short-range communications subsystem 1040, and any other device subsystems generally designated at 1042. Some of the subsystems shown perform communication-related functions, whereas other subsystems may provide “resident” or on-device functions. Notably, some subsystems, such as keyboard 1032 and display 1022, for example, may be used for both communication-related functions, such as entering a text message for transmission over a communication network, and device-resident functions such as a calculator or task list. Operating system software used by microprocessor 1038 is preferably stored in a persistent store such as flash memory 1024, which may alternatively be a read-only memory (ROM) or similar storage element (not shown). Those skilled in the art will appreciate that the operating system, specific device applications, or parts thereof, may be temporarily loaded into a volatile store such as RAM 1026.
Microprocessor 1038, in addition to its operating system functions, preferably enables execution of software applications on handheld device 1002. A predetermined set of applications that control basic device operations, including at least data and voice communication applications, will normally be installed on handheld device 1002 during its manufacture. A preferred application that may be loaded onto handheld device 1002 may be a personal information manager (PIM) application having the ability to organize and manage data items relating to a user such as, but not limited to, e-mail, calendar events, voice mails, appointments, and task items. Naturally, one or more memory stores are available on handheld device 1002 and memory module 1062 to facilitate storage of PIM data items and other information.
The PIM application preferably has the ability to send and receive data items via the wireless network. In a preferred embodiment, PIM data items are seamlessly integrated, synchronized, and updated via the wireless network, with the mobile station user's corresponding data items stored and/or associated with a host computer system thereby creating a mirrored host computer on handheld device 1002 with respect to such items. This is especially advantageous where the host computer system is the mobile station user's office or enterprise computer system. Additional applications may also be loaded onto handheld device 1002 through network, an auxiliary I/O subsystem 1028, serial port 1030, short-range communications subsystem 1040, or any other suitable subsystem 1042, and installed by a user in RAM 1026 or preferably a non-volatile store (not shown) for execution by microprocessor 1038. Such flexibility in application installation increases the functionality of handheld device 1002 and may provide enhanced on-device functions, communication-related functions, or both. For example, secure communication applications may enable electronic commerce functions and other such financial transactions to be performed using handheld device 1002.
In a data communication mode, a received signal such as a text message, an e-mail message, or web page download will be processed by communication subsystem 1011 and input to microprocessor 1038. Microprocessor 1038 will preferably further process the signal for output to display 1022 or alternatively to auxiliary I/O device 1028. A user of handheld device 1002 may also compose data items, such as e-mail messages, for example, using keyboard 1032 in conjunction with display 1022 and possibly auxiliary I/O device 1028. Keyboard 1032 is preferably a complete alphanumeric keyboard and/or telephone-type keypad. These composed items may be transmitted over a communication network through communication subsystem 1011.
For voice communications, the overall operation of handheld device 1002 is substantially similar, except that the received signals would be output to speaker 1034 and signals for transmission would be generated by microphone 1036. Alternative voice or audio I/O subsystems, such as a voice message recording subsystem, may also be implemented. Although voice or audio signal output is preferably accomplished primarily through speaker 1034, display 1022 may also be used to provide an indication of the identity of a calling party, duration of a voice call, or other voice call related information, as some examples.
Serial port 1030 in
Short-range communications subsystem 1040 is an additional optional component that provides for communication between handheld device 1002 and different systems or devices, which need not necessarily be similar devices. For example, subsystem 1040 may include an infrared device and associated circuits and components, or a Bluetooth™ communication module to provide for communication with similarly enabled systems and devices. Bluetooth™ is a registered trademark of Bluetooth SIG, Inc.
Handheld device 1002 may be configured such as via software (instructions and data stored in memory) to provide the system and method for navigating among visual elements described above.
The systems and methods according to the present patent disclosure may be implemented by any hardware, software or a combination of hardware and software having the above described functions. The software code, either in its entirety or a part thereof, may be stored in a computer-readable memory. Further, a computer data signal representing the software code which may be embedded in a carrier wave may be transmitted via a communication network. Such a computer-readable memory and a computer data signal are also within the scope of the present patent disclosure, as well as the hardware, software and the combination thereof.
While particular embodiments of the present patent disclosure have been shown and described, changes and modifications may be made to such embodiments without departing from the true scope of the patent disclosure.