Multi-input gestures permit users to selectively manipulate regions within application interfaces, such as webpages. These multi-input gestures permit many manipulations difficult or impossible with single-input gestures. For example, multi-input gestures can permit zooming in or out of a map in a webpage, panning through a list on a spreadsheet interface, or rotating a picture of a graphics interface. Conventional techniques for handling multi-input gestures, however, often associate a gesture with a region that was not intended by the user.
This document describes techniques for multi-input gestures in hierarchical regions. These techniques determine an appropriate region of multiple, hierarchically related regions to associate a multi-input gesture. By so doing, a user may input a multi-input gesture into an application interface and, in response, the application interface manipulates the region logically and/or as intended by the user.
This summary is provided to introduce simplified concepts for multi-input gestures in hierarchical regions that are further described below in the Detailed Description. This summary is not intended to identify essential features of the claimed subject matter, nor is it intended for use in determining the scope of the claimed subject matter. Techniques and/or apparatuses for multi-input gestures in hierarchical regions are also referred to herein separately or in conjunction as the “techniques” as permitted by the context.
Embodiments for multi-input gestures in hierarchical regions are described with reference to the following drawings. The same numbers are used throughout the drawings to reference like features and components:
Overview
This document describes techniques and apparatuses for multi-input gestures in hierarchical regions. These techniques enable applications to appropriately respond to a multi-input gesture made to one or more hierarchically related regions of an application interface.
Assume, for example, that a user wishes to expand an application interface to fit the user's screen. Assume also that the application has three different regions, one of which is hierarchically superior to the other two. If the user makes a zoom-out (e.g., spread or diverge) multi-input gesture where his or her fingers apply to different regions, current techniques often expand one of the inferior regions within the application interface or pan both of the inferior regions.
The techniques described herein, however, appropriately associate the multi-input gesture with the superior region, thereby causing the application interface to fill the user's screen. The techniques may do so, in some cases, based on the hierarchy of the regions and the capabilities of each region with respect to a received multi-input gesture.
This is but one example of the many ways in which the techniques enable users to manipulate regions of an application interface. Numerous other examples, as well as ways in which the techniques operate, are described below.
This discussion proceeds to describe an example environment in which the techniques may operate, methods performable by the techniques, and an example apparatus.
Example Environment
Computing device 102 includes or has access to computer processor(s) 202, computer-readable storage media 204 (media 204), and one or more displays 206, four examples of which are illustrated in
Gesture manager 210 is capable of targeting a multi-input gesture 114 received through an application interface (e.g., interfaces 108, 110, and/or 214) to a region of the application of the interface.
Ways in which entities of
Block 402 receives, from an application associated with an application interface, information about multiple regions of the application interface. This information can include hierarchical relationships, such as which regions are superior to which others, a size, location, and orientation of each region within the application interface and/or display (e.g., which pixels are of each region), and a response capability to multi-input gestures of each region.
By way of example, consider
For this example assume that gesture manager 210 receives the hierarchical relationships and which multi-input gestures each region can accept. Here all four regions can accept a pinch/spread or converge/diverge gesture (often used to zoom out or in), in the case of region 502 the divergence gesture expands all of application interface 110 (e.g., to the size of touch-screen display 112), and each of regions 504, 506, and 508 accept the divergence gesture to expand the news article associated with that region within the current size of application interface 110. Note, however, that other responses may also or instead be used, such as to show in a same-sized region a higher resolution of content, in which case some of the content may cease to be shown.
Block 404 receives a multi-input gesture having two or more initial touches (direct, indirect, or however received) made to an application interface having a superior region and at least one inferior region. In some cases the multi-input gesture is received from a device directly, such as touch-screen display 112, while in other cases the gesture is received from the application associated with the application interface or an operating system. Thus, the form of reception for the multi-input gesture can vary—it can be received as touch hits indicating locations on the application interface through which the gesture is received. In other cases, such as when received from application 212, the multi-input gesture is instead received with a indication of which regions the initial touches where received (e.g., one touch to superior region 502 and one touch to inferior region 508).
Method 400 addresses the scenario where the multi-input gesture is received having an indication of which region of an application interface the initial touches are made. Method 700 of
Continuing the ongoing embodiment, consider
Block 406 targets the multi-input gesture to an appropriate region. Generally, block 406 targets to the superior region if the superior region is capable of responding to the multi-input gesture and at least one of the two or more initial touches is made to the superior region, or the superior region is capable of responding to the multi-input gesture and the two or more initial touches are made to at least two different inferior regions.
In some cases block 406 targets also to the superior region outside of these two cases, such as if the superior region is capable of responding to the multi-input gesture and the two or more initial touches are made to a same or different inferior regions but the same inferior region or the different inferior regions are not capable of responding to the multi-input gesture.
Thus, there are cases where the multi-input gesture is not targeted to the superior region. For example, block 406 may target the multi-input gesture to the inferior region if the inferior region is capable of responding to the multi-input gesture and the two or more initial touches are made to only the inferior region.
The targeting of block 406 is based on at least some of the information received at block 402. In the above general cases, gesture manager 210 targets to an appropriate region based on the hierarchy of the regions, to which region(s) the initial touches are made, and the capabilities of at least the superior region. As part of block 406, the application associated with the application interface is informed of the targeting, such as with an indication of which region should respond to the multi-input gesture. How this is performed depends in part on whether gesture manager 210 is integral or separate from application 212, operating system 208, services 306, and/or device-specific software, such as a driver of touch-screen display 112.
Consider again the ongoing example illustrated in
Gesture manager 210 then indicates this targeting to application 212 effective to cause application 212 to respond to the multi-input gesture, which in this case is a spread/diverge gesture (shown at arrow 608). Concluding the ongoing example, application 212 responds to a divergence gesture by expanding application interface 110 to a larger size, here most of the screen of touch-screen display 112, shown also in
Note that in some cases one of the initial touches of a multi-input gesture is received before the other(s). In such a case the techniques may immediately target the first initial touch to the region in which it is received. By so doing, very little if any user-perceivable delay is created, because the application may quickly respond to this first initial touch. Then, if no other touch is made, or a subsequent touch cannot be used (e.g., it is deemed a mistake or no region can respond to it), the region still responded quickly. When the second initial touch is received the techniques then target as noted in method 400.
Altering the above example, assume that initial touch 606 is received first. Gesture manager 210 targets this touch to inferior region 504 in which it was received. Application 212 then begins to respond, such as by altering the region by scrolling down in the article entitled: Social Networking IPO Expected Next Week. When the second touch is received, the above proceeds as shown at 610 in
Block 702 receives information about multiple regions of an application interface including size, location, and/or orientation of each of the regions. Block 702 is similar to block 402 of method 400, as it also receives information about the hierarchy and capabilities of the regions.
Block 704 receives touch hits associated with two or more initial touches for one or more multi-input gestures received through the application interface, the touch hits indicating location information on the application interface where the touch hits are received. Thus, gesture manager 210, for example, may receive location information indicating which pixel or pixels of a display are initially touched, an X-Y coordinate, or other location information sufficient to determine to which region a touch is intended. These touch hits may be received from application 212, directly from a device or device driver, or indirectly from operating system 208, to name just a few.
Block 706 determines, based on the touch hits, to which of said regions the two or more initial touches are associated. Gesture manager 210 may do so in various manners, such as by comparing a pixel or coordinate hit with location information received at block 702.
Block 708 determines, based on the associated regions, the hierarchy of the associated regions, and the response capabilities of the associated regions, at least one region of the associated regions to target. Thus, gesture manager 210 may determine that superior region 502 should respond to the multi-input gesture received.
Block 710 targets the targeted region(s) effective to cause the application to respond to the multi-input gesture(s) through the targeted region(s). Block 710 provides, for example, a targeted region to the application after which the application responds to one multi-input gesture through the targeted region. As shown in
By way of further example, consider a case where gesture manager 210 targets a multi-input gesture to inferior region 506 due to inferior region 506 being capable of receiving the multi-input gesture and both initial touches landing within region 506 of
The preceding discussion describes methods relating to multi-input gestures in hierarchical regions. Aspects of these methods may be implemented in hardware (e.g., fixed logic circuitry), firmware, software, manual processing, or any combination thereof A software implementation represents program code that performs specified tasks when executed by a computer processor. The example methods may be described in the general context of computer-executable instructions, which can include software, applications, routines, programs, objects, components, data structures, procedures, modules, functions, and the like. The program code can be stored in one or more computer-readable memory devices, both local and/or remote to a computer processor. The methods may also be practiced in a distributed computing mode by multiple computing devices. Further, the features described herein are platform-independent and can be implemented on a variety of computing platforms having a variety of processors.
These techniques may be embodied on one or more of the entities shown in environment 100 of
Device 900 includes communication devices 902 that enable wired and/or wireless communication of device data 904 (e.g., received data, data that is being received, data scheduled for broadcast, data packets of the data, etc.). The device data 904 or other device content can include configuration settings of the device, media content stored on the device, and/or information associated with a user of the device. Device 900 includes one or more data inputs 906 via which any type of data, media content, and/or inputs can be received, such as human utterances, user-selectable inputs, messages, music, television media content, recorded video content, and any other type of data received from any content and/or data source.
Device 900 also includes communication interfaces 908, which can be implemented as any one or more of a serial and/or parallel interface, a wireless interface, any type of network interface, a modem, and as any other type of communication interface. The communication interfaces 908 provide a connection and/or communication links between device 900 and a communication network by which other electronic, computing, and communication devices communicate data with device 900.
Device 900 includes one or more processors 910 (e.g., any of microprocessors, controllers, and the like), which process various computer-executable instructions to control the operation of device 900 and to enable techniques for multi-input gestures in hierarchical regions. Alternatively or in addition, device 900 can be implemented with any one or combination of hardware, firmware, or fixed logic circuitry that is implemented in connection with processing and control circuits which are generally identified at 912. Although not shown, device 900 can include a system bus or data transfer system that couples the various components within the device. A system bus can include any one or combination of different bus structures, such as a memory bus or memory controller, a peripheral bus, a universal serial bus, and/or a processor or local bus that utilizes any of a variety of bus architectures.
Device 900 also includes computer-readable storage media 914, such as one or more memory devices that enable persistent and/or non-transitory data storage (i.e., in contrast to mere signal transmission), examples of which include random access memory (RAM), non-volatile memory (e.g., any one or more of a read-only memory (ROM), flash memory, EPROM, EEPROM, etc.), and a disk storage device. A disk storage device may be implemented as any type of magnetic or optical storage device, such as a hard disk drive, a recordable and/or rewriteable compact disc (CD), any type of a digital versatile disc (DVD), and the like. Device 900 can also include a mass storage media device 916.
Computer-readable storage media 914 provides data storage mechanisms to store the device data 904, as well as various device applications 918 and any other types of information and/or data related to operational aspects of device 900. For example, an operating system 920 can be maintained as a computer application with the computer-readable storage media 914 and executed on processors 910. The device applications 918 may include a device manager, such as any form of a control application, software application, signal-processing and control module, code that is native to a particular device, a hardware abstraction layer for a particular device, and so on.
The device applications 918 also include any system components, engines, or modules to implement techniques for multi-input gestures in hierarchical regions. In this example, the device applications 918 can include gesture manager 210 and applications 212.
Although embodiments of techniques and apparatuses for multi-input gestures in hierarchical regions have been described in language specific to features and/or methods, it is to be understood that the subject of the appended claims is not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as example implementations for multi-input gestures in hierarchical regions.