Adjusting operating system posture for a touch-enabled computing device based on user input modality signals

Techniques for adjusting a posture of an operating system mode for a touch-enabled computing device based on combinations of user preferences and user input modality signals. Various adjustments to the posture of the operating system mode do not impact whether particular user interface elements are present but rather alter characteristics with which these particular user interface elements are rendered. Posture adjustments to an operating system mode occur based on combinations user input modality signals and user preferences not to enter another mode in which particular user interface elements are no longer displayed within a task bar along a peripheral edge. An object of designing an operating system mode to have multiple different postures with common user interface elements displayed in the task bar while adjusting the characteristics thereof is to preserve the user familiarity across postures while optimizing graphical layouts to accommodate for a current user input modality.

BACKGROUND

A variety of touch-enabled computing devices are configured to operate in two highly discrete modes with drastically different graphical user interfaces depending on a current modality of user input. In particular, at times when a peripheral-type keyboard user input device is attached, some touch-enabled computing devices by default operate in a desktop mode having a graphical user interface with a task bar located along a perimeter edge (e.g., the bottom) and comprised of relatively small icons that individually represent operating system functionalities and currently executing applications. Then, in response to the keyboard being detached, such touch-enabled devices automatically switch to a tablet mode having a graphical user interface that is very different in the sense that one or more of these small icons that were previously located around the perimeter edge within the task bar are absent and replaced with relatively larger tile type icons that are displayed in a centrally located grid arrangement. Accordingly, the two different modes include completely different user interface elements and require drastically different interaction patterns to invoke similar actions.

A major drawback of toggling a touch-enabled computing device between highly discrete modes with very different graphical user interfaces is that correlations between how to invoke similar or identical functions may be highly non-intuitive between modes. For example, suppose that a user is actively toggling between using two applications while in desktop mode by clicking icons that represent these two applications in the task bar. Then, the user may detach the keyboard with the intention of continuing to switch between the two applications. However, to the user's dismay, removal of the keyboard may trigger the device to operate in the tablet mode in which the icons representing the applications are absent from the task bar and the interaction patterns which cause the device to switch between the two applications are drastically different than they previously were in the desktop mode that the user was accustomed to. Accordingly, in order to continue switching between using the applications the user must learn and utilize a completely different manner of interacting with the touch-enabled computing device.

In scenarios in which the user is knowledgeable of how to perform desired tasks (e.g., switching between applications) in each discrete mode, having to consciously make significant adjustments to current user interactions patterns when slight user input modality changes occur can be highly disruptive. Even worse, in scenarios in which the user is knowledgeable of how to perform desired tasks in only a preferred one of the discrete modes, even a slight change in user input modality (e.g., detachment of a keyboard) may severely hamper the user's productivity. For this reason, many users define system preferences to prevent a touch-enabled computing device from toggling from the familiar desktop mode into the tablet mode notwithstanding various changes to a current user input modality.

SUMMARY

This disclosure describes systems and techniques for adjusting a posture of an operating system mode for a touch-enabled computing device based on combinations of user preferences and user input modality signals. Generally described, various adjustments to the posture of the operating system mode do not impact whether particular user interface elements are present but rather alter characteristics with which these particular user interface elements are rendered on the touch-enabled computing device, interacted with on the touch-enabled computing device, or both. In some implementations, posture adjustments in which characteristics of the particular user interface elements are altered may occur in response to combinations of changes to user input modality signals and user preferences indicating a user preference not to enter a specific mode (e.g., a “tablet mode”) in which the particular user interface elements are no longer displayed within a task bar along a peripheral edge. An object of designing an operating system mode to have multiple different postures with common user interface elements displayed in a task bar along a peripheral edge while adjusting the characteristics thereof is to preserve the user familiarity across postures while optimizing graphical layouts (e.g., spacing between user interface elements) and/or interaction patterns to accommodate for a current user input modality. In this way, the particular user interface elements that users are already accustomed to selecting (or otherwise interacting with) to invoke certain functionalities remain available across different postures of an operating system mode (e.g., different postures of a “desktop” mode). At the same time, certain characteristics of these particular user interface elements are optimally adjusted to accommodate the current manner in which a user can potentially interact with those user interface elements (e.g., touchpad input if a peripheral keyboard is attached vs. touch-screen input if the peripheral keyboard is detached).

In one embodiment, a touch-enabled computing device executes an operating system that is configured to operate in accordance with at least two different modes based on user preference data. For example, the user preference data may indicate particular circumstances in which the operating system is to operate in accordance with a first mode (e.g., a “desktop mode”) having a graphical user interface (GUI) that includes a task bar located along a perimeter edge (e.g., the bottom) of a display area. The task bar may be comprised of OS function icons (e.g., user interface elements that represent certain operating system functionalities) and application icons (e.g., user interface elements that represent currently executing applications). An exemplary OS function icon may be an OS search icon that is selectable to call upon an OS Search functionality for searching through local directories and/or web-based resources based on a user-defined search string. An exemplary application icon may be a web browser icon that is selectable to bring forward (or otherwise expose) a browser application window for a web browser application that is open on the touch-enabled computing device.

Here, under circumstances in which the user preference data indicates a user preference to have the operating system toggle into the second mode in response to the predefined user input modality signals, then the touch-enable computing device may monitor various data sources to determine when such predefined user input modality signals occur. Then, in response to an occurrent of such predefined user input modality signals, the operating system may toggle into the second mode. For example, based on the user preference data, the operating system may respond to a peripheral keyboard being detached from the touch-enabled computing device by immediately and automatically switching into the tablet mode.

In contrast, if the user preference data instead indicates a user preference that the operating system does not toggle into the second mode even when such predefined user input modality signals are detected (e.g., even if a keyboard is detached as described above), then detection of the predefined user input modality signals may cause the operating system to adjust a posture of the first mode having the task bar that is located along the perimeter edge of the display area and that includes the user interface elements that represent the operating system functionalities in addition to the currently executing applications. Here, the user input modality signals may indicate that user inputs are more likely to be received via a touchscreen than a touchpad. For example, the user input modality signals may correspond to a keyboard device becoming detached and/or accelerometer data indicating that the touch-enabled computing device is being held in a manner that is not optimal for keyboard usage. Then, in response to the detected user input modality signals, the touch-enabled computing device may automatically adjust the posture of the first mode in a manner such that the OS function icons and application icons continue to be rendered within the task bar along the peripheral edge but are linearly spaced farther apart within the task bar to improve touchscreen based interactions with the touch-enabled computing device.

In this example, operation of the touch-enabled device remains intuitive in the sense that a user can still cause the operating system to invoke particular functions by selecting the same user interface elements which were present in the task bar prior to the peripheral user input device becoming unavailable. At the same time, the increased linear spacing between these user interface elements improves an ability for individual ones of these user interface elements to be selected via a touch screen (e.g., a capacitive sensing display). For example, since a curser element is no longer being rendered to indicate precisely which user interface element is being hovered over prior to a user clicking a button to complete the selection, the increased spacing reduces the probability of the user inadvertently selecting an icon that is adjacent to an intended or targeted icon.

DETAILED DESCRIPTION

The following Detailed Description describes techniques for adjusting a posture of an operating system mode for a touch-enabled computing device based on combinations of user preferences and user input modality signals. Various adjustments to the posture of the operating system mode do not impact whether particular user interface elements are present but rather alter characteristics with which these particular user interface elements are rendered and/or interacted with on the touch-enabled computing device. Posture adjustments to an operating system mode (e.g., a “desktop mode”) may occur based on combinations user input modality signals and user preferences not to enter another mode (e.g., a “tablet mode”) in which particular user interface elements are no longer displayed within a task bar along a peripheral edge. An object of designing an operating system mode to have multiple different postures with common user interface elements displayed in a task bar along a peripheral edge while adjusting the characteristics thereof is to preserve the user familiarity across postures while optimizing graphical layouts and/or interaction patterns to accommodate for a current user input modality. In this way, the particular user interface elements that users are already accustomed to selecting to invoke certain functionalities remain available across different postures of an operating system mode (e.g., different postures of a “desktop” mode). At the same time, certain characteristics of these particular user interface elements are optimally adjusted to accommodate the current manner in which a user can potentially interact with those user interface elements.

FIG. 1illustrates an exemplary scenario for a touch-enabled computing device100to adjust a posture of a first operating system mode for a touch-enabled computing device based on combinations of user preferences and user input modality signals. The technologies disclosed herein with respect to the system100provide improvements over existing touch-enabled computing devices which lack an ability to automatically adjust the posture of individual operating system modes by altering characteristics with which common user interface elements are rendered (e.g., spaced within a task bar) to accommodate for a current user input modality. For example, as described above, existing touch-enabled computing devices respond to certain trigger events (e.g., a user removing a peripheral keyboard) by toggling between highly discrete modes with very different graphical user interfaces. A drawback of such implementations is that correlations between how to invoke similar or identical functions may be highly non-intuitive between the drastically different operating system modes. For example, user interaction patterns for invoking certain functions and/or tasks within a desktop mode may bear little resemblance to other user interaction patterns for invoking these same functions within a tablet mode. Accordingly, toggling between drastically different operating system modes may disrupt productivity since a user may need to consciously adjust how they are interacting with a device or, even worse, the user may not even understand how to perform certain desired tasks after the device switches into some particular mode. In contrast, the techniques described herein facilitate relatively subtle posture changes to occur within a single operating system mode to accommodate for a currently relevant user input modality.

As illustrated inFIG. 1, the touch-enabled computing device100may utilize hardware (e.g., processors, memory, etc.) to execute an operating system102that performs one or more of the various operations described herein and/or to store various types of data described herein. In the illustrated embodiment, the operating system102includes user preference data104indicating various user preferences associated with the operation of the touch-enabled computing device100and OS mode data106defining various operational modes in which the operating system102can execute on the touch-enabled computing device100. Exemplary user preferences which can be defined within the user preference data104include, but are not limited to, a user defined name of the touch-enabled computing device (e.g., “Bob's Surface Pro”), startup options that prescribe which applications run automatically upon the touch-enabled computing device100being booted up, and OS Mode preferences indicating if and when the operating system102is to toggle between different operational modes. Exemplary operational modes which can be defined within the OS Mode data106include, but are not limited to, a first mode108(1) having a graphical user interface (GUI) that includes a task bar located along a perimeter edge (e.g., the bottom) of a display area, and a second mode108(2) having an alternative GUI and/or alternative user interaction patterns for invoking certain tasks.

For purposes of the present discussion ofFIG. 1, presume that the first mode108(1) corresponds to a “desktop mode” in which a task bar located along a peripheral edge of an available display area is comprised of OS function icons (e.g., user interface elements that represent certain operating system functionalities) and application icons (e.g., user interface elements that represent currently executing applications). An exemplary OS function icon may be an OS search icon that is selectable to call upon an OS Search functionality for searching through local directories and/or web-based resources based on a user-defined search string. An exemplary application icon may be a web browser icon that is selectable to bring forward (or otherwise expose) a browser application window for a web browser application that is open on the touch-enabled computing device. Further presume that the second mode108(2) corresponds to a “tablet mode” in which one or more application icons which were previously displayed within the task bar are omitted from the task bar and replaced with relatively larger tile icons that are centrally located within the display area in a grid arrangement. For example, in a “tablet mode” the task bar may include only the OS function icons but may omit the application icons which may instead be enlarged into tile form and centrally located within the display area.

As used herein, the term “mode” may be used to refer to a computing mode in which a predefined set of user interface elements are rendered within a predefined graphical region of an available display area. For example, a “desktop” mode may refer to a particular computing mode in which a predefined graphical region is a taskbar that is rendered along a peripheral edge of an available display area and which includes a predefined set of OS functionality icons in addition to one or more application icons (if applications are currently executing on a computing device). As used herein, the term “posture” may be used to refer to a particular graphical configuration of a particular mode. For example, a single computing “mode” may include two or more postures that define various manners and/or characteristics of graphically rendering a predefined set of user interface elements within a predefined graphical region of an available display area. As a specific but non-limiting example, if a particular computing mode corresponds to a predefined set of user interface elements being rendered within a task bar that is rendered along a peripheral edge of a display area, then various postures of the particular computing mode may correspond to different linear spacings between adjacent ones of the predefined set of user interface elements.

As illustrated, one or more integrated user input/output (I/O) devices112are installed within the touch-enabled computing device100. Integrated user I/O device(s)112include at least a touchscreen114which serves as both an output device through which user interface elements (and other information) are displayed and an input device through which a user can interact with the displayed user interface elements by touching the touchscreen114with her fingers and/or a stylus. In particular, the touchscreen114is an input device configured to detect the presence and location of a touch. The touchscreen114can be a resistive touchscreen, a capacitive touchscreen, a surface acoustic wave touchscreen, an infrared touchscreen, an optical imaging touchscreen, a dispersive signal touchscreen, an acoustic pulse recognition touchscreen, or can utilize any other touchscreen technology. In some embodiments, the touchscreen114is incorporated on top of a display (e.g., an OLED display) as a transparent layer to enable a user to use one or more touches to interact with objects or other information presented on the display.

In some configurations, the touchscreen114is a single-touch touchscreen. In other configurations, the touchscreen114is a multi-touch touchscreen. In some configurations, the touchscreen114is configured to detect discrete touches, single touch gestures, and/or multi-touch gestures. These are collectively referred to herein as “gestures” for convenience. Several gestures will now be described. It should be understood that these gestures are illustrative and are not intended to limit the scope of the appended claims. Moreover, the described gestures, additional gestures, and/or alternative gestures can be implemented in software for use with the touchscreen114. As such, a developer can create gestures that are specific to a particular application program.

Additionally, the touch-enabled computing device100includes one or more sensor(s)116. Exemplary sensors116include, but are not limited to, a proximity sensor that is configured to detect the presence of an object or thing in proximity to the touch-enabled computing device100without direct contact, an accelerometer that is configured to measure proper acceleration, and/or a gyroscope that is configured to measure and maintain orientation. In some configurations, output from one or more of the proximity sensor, accelerometer, or gyroscope is used by the operating system102as an input mechanism to determine an appropriate mode108and/or posture110thereof to operate in accordance with.

As shown inFIG. 1, the touch-enabled computing device100may be communicatively coupled to and de-coupled from a peripheral user input device118. An exemplary such peripheral user input device118may magnetically couple to the touch-enabled computing device100and may include both of a touchpad120and a physical keyboard122. Furthermore, the touch-enabled computing device100may be configured to determine a current availability status of the peripheral user input device118. For example, the touch-enabled computing device100may be configured to continually monitor whether the peripheral user input device118is available for the user to provide user input to the touch-enabled computing device100.

Aspects of the exemplary scenario for the touch-enabled computing device100to adjust the posture110of the first operating system mode108(1) inFIG. 1are described with respect to a first time T1through a fifth time T5. For purposes of the present discussion, these times represent a sequence of times in which: T1<T2<T3<T4<T5(where < means “prior to”).

As illustrated, at a first time T1, first user input124(1) is provided to modify the user preference data104to indicate a user preference that the operating system102does not toggle into the second mode108(8) notwithstanding the occurrence of some predefined trigger event. For purposes of the present scenario, presume that the predefined trigger event corresponds to the peripheral user input device118being disconnected from the touch-enabled computing device100. This relatively simple trigger event is utilized for exemplary purposes only and it will be appreciated from the following discussion that in various embodiments combinations of multiple different user input modality signals may be used to serve as the trigger event.

At time T2, the touch-enabled computing device100operates in accordance with a first posture110(1) of the first mode108(1) in which a task bar is located along a peripheral edge of an available display area is comprised of OS function icons (e.g., user interface elements that represent certain operating system functionalities) and application icons (e.g., user interface elements that represent currently executing applications). Here, the touch-enabled computing device100may be operating in the first posture110(1) of the first mode108(1) (e.g., the “desktop mode”) responsive to a determination that the predefined trigger event (e.g., which the user has indicated should not result in/trigger operation in the second mode108(2)) has not occurred. For example, based on the current presumption that the predefined trigger event corresponds to the peripheral user input device118being disconnected from the touch-enabled computing device100, at time T2the touch-enable computing device100operates in accordance with the first posture110(1) of the first mode108(1) due to the peripheral user input device118being connected to the touch-enabled computing device100at time T2.

At time T3, second user input124(2) is being provided to the touch-enabled computing device100by way of the peripheral user input device118. For example, a user may be performing finger gestures on the touchpad120and/or may be typing by pressing physical keys of the physical keyboard122.

Then, at time T4, the operating system102receives user input modality signals126indicating that the peripheral user input device (PUID)118has been disconnected from the touch-enabled computing device100. As described above, the user preference data104indicates a user preference not to switch the operating system102from the first mode108(1) into the second mode108(2).

Accordingly, at time T5, the touch-enabled computing device100responds to the combination of the user input modality signals126indicating that the predefined trigger event has occurred and the user preference data104indicating that the predefined trigger event is not to cause the operating system102to toggle operation into the second mode108(2) (e.g., the “tablet mode”) by adjusting the first mode108(1) from the first posture110(1) to a second posture110(2) which retains common user interface elements (also referred to herein as “icons”) within the task bar that is located along the perimeter edge of the display area but that adjust a linear spacing between the icons within the task bar. For example, in response to detecting the user input modality signals126indicating that the PUID118has been disconnected and the user preference data104precluding such user input modality signals126from triggering operation of the operating system102in the second mode108(2), the touch-enabled computing device100may automatically adjust the posture of the first mode108(1) in a manner such that the OS function icons and application icons continue to be rendered within the task bar along the peripheral edge but are linearly spaced farther apart within the task bar to better facilitate interactions with the touch-enabled computing device100via the touchscreen114.

In some embodiments, the predefined trigger event may correspond to a touchscreen usage exceeding a threshold usage level. For example, the touch-enabled computing device100may monitor both user input received by way of the touchscreen114and/or user input received by way of the touchpad120. Then, based on the ratio of first user inputs received by way of the touchscreen114to second user inputs received by way of the touchpad120exceeding a threshold, the touch-enabled computing device100may determine that the trigger event has occurred. As a specific but non-limiting example, if over a predetermined time interval (e.g., the last five minutes, or any other suitable time interval) eighty percent or more of all user input to the touch-enabled computing device is received via the touchscreen114and twenty percent or less is received via the touchpad120, then the touch-enabled computing device may determine that the predefined trigger event has occurred.

Turning now toFIG. 2AthroughFIG. 2D, example scenarios are illustrated in which the touch-enabled computing device100operates in accordance with various different postures110of various operating system modes108based on combinations of user input modality signals and user preferences. It should be appreciated that various aspects described in relation to one or more ofFIG. 2AthroughFIG. 2Dmay be omitted from the example scenarios with which those aspects are described in relation to and/or combined with aspects of other example scenarios. Furthermore, the limited number of example scenarios described herein are for illustrative purposes only and are not to be construed as limiting. Performance of various aspects of the techniques described herein are contemplated under many other factual scenarios.

FIG. 2Aillustrates a scenario in which the touch-enabled computing device100is operating in accordance with the first posture110(1) of the first mode108(1). As illustrated in scenario A, the touch-enabled computing device100has detected user input modality signals126that include a combination of the peripheral user input device118being currently connected to the touch-enabled computing device100in addition a kickstand angle (represented by the “θ” symbol) being greater than a threshold angle.

For purposes of the present discussion, presume that in terms of design parameters the user input modality signals126shown inFIG. 2Aare considered to be indicative that the peripheral user input device118will be the currently preferred channel (e.g., mode) for providing user input. Further suppose that responsive to receiving user inputs via the touchpad120of the peripheral user input device118, the operating system causes a curser202to move around a display area204of a display screen206. In the illustrated embodiment, while operating in the first posture110(1) of the first mode108(1), a hovering graphical effect208may be rendered in relation to a particular user interface element210on which the curser202is currently placed over. For example, as illustrated, the curser202is currently placed over a second user interface element210(2) that is selectable to invoke a “Talk to Assistance” OS functionality. The hovering graphical effect208may include adjusting a background color of the particular user interface element210(e.g., to provide contrast to distinguish the particular user interface element210from other user interface elements which the curser202is not currently placed over). Additionally, or alternatively, the hovering graphical effect208may include exposing a written description212of the OS functionality and/or application to which the particular user interface element210corresponds. As illustrated, for example, the curser202being currently placed over the second user interface element210(2) causes the words “Talk to Assistant” to be exposed adjacent to (e.g., directly above) the second user interface element210(2) to inform a user of the OS functionality which can be invoked by selecting the second user interface element210(2).

As illustrated, the first mode108(1) in which the operating system102may operate corresponds to a “desktop mode” having a graphical user interface (GUI) that includes a task bar216located along a perimeter edge (e.g., the bottom) of the display area204. The task bar216may include a plurality of OS function icons (e.g., user interface elements that represent certain operating system functionalities) and/or application icons (e.g., user interface elements that represent currently executing applications). An exemplary OS function icon may be an OS search icon that is selectable to call upon an OS Search functionality for searching through local directories and/or web-based resources based on a user-defined search string. An exemplary application icon may be a Team Collaboration application icon that is selectable to bring forward (or otherwise expose) a Team Collaboration window for a Team Collaboration application that is open on the touch-enabled computing device100. In the illustrated example, the first user interface element210(1) through the third user interface element210(3) are representative of OS function icons whereas the fourth user interface element210(4) is a representative application icon.

As further illustrated, while operating in accordance with the first posture110(1) of the first mode108(1), the user interface elements210are rendered with a first spacing therebetween. Specifically, the first posture110(1) prescribes that the linear Distance D1be provided in between the user interface elements210within the task bar216. Furthermore, while operating in the first posture110(1) of the first mode108(1), an OS Search icon (which corresponds to the first user interface element210(1)) includes an exposed user input field into which a user can enter a search string in association with the OS search functionality.

FIG. 2Billustrates a scenario in which the touch-enabled computing device100is operating in accordance with the second posture110(2) of the first mode108(1) (e.g., the “desktop” mode in which the task bar216is rendered along a peripheral edge of the display area204and in which the task bar216includes the user interface elements210that are commonly shared with the first posture110(1)). As illustrated in scenario B, the touch-enabled computing device100has detected user input modality signals126that include a combination of the peripheral user input device118being currently disconnected from the touch-enabled computing device100, the kickstand angle being less than the threshold angle, and accelerometer data being consistent with the device100being held (e.g., the device100may be subject to some degree of shaking or other motion which indicates it is not resting on a stable surface such as a table of desk).

For purposes of the present discussion, presume that in terms of design parameters the user input modality signals126shown inFIG. 2Bare considered to be indicative that the touchscreen114will be the currently preferred channel (e.g., mode) for providing user input. For example, while operating in accordance with the first posture110(1), the touch-enabled computing device100may receive user input modality signals126indicating that a most likely user input modality has changed from a first input modality to a second input modality. For example, the user input modality signals may indicate that inputs are more likely to be received via the touchscreen114than the touchpad120, or vice versa. Exemplary such user input modality signals126may include a combination of a keyboard device becoming detached or otherwise unavailable (e.g., accelerometer data indicating that the touch-enabled computing device is being held in a manner that is not optimal for keyboard usage).

For purposes of the present discussion, presume that the change to the user input modality signals126between scenarios A and B has resulted in a posture adjustment from the first posture110(1) shown inFIG. 2Ato the second posture110(2) shown inFIG. 2B. As can be appreciated from a comparison ofFIGS. 2A to 2B, the posture adjustment from the first to second posture may include collapsing a particular user interface element210(1) of the task bar216and increasing a linear spacing between the plurality user interface elements210within the task bar. For example, as shown inFIG. 2B, the user input field into which a user can enter a search string in association with the OS search functionality has been collapsed or hidden so that the first user interface element210(1) takes up less horizontal space within the task bar216. Collapsing or otherwise reducing the horizontal space taken up by the first user interface element210(1) allows for an increased linear spacing between the user interface elements210that represent the represent available operating system functions and/or currently running applications. For example, as illustrated, while operating in accordance with the second posture110(2) of the first mode108(1), the user interface elements210are rendered with a second spacing therebetween. Specifically, the second posture110(2) prescribes that the linear Distance D2be provided in between the user interface elements210within the task bar216, where the linear Distance D2is greater than the linear Distance D1.

As opposed to having the user input modality signals126of scenario B cause the device100to enter a tablet mode in which various user interface elements210are no longer rendered in the task bar, an object of designing the first operating system mode108(1) to have multiple different postures with common user interface elements displayed in the task bar216along a peripheral edge while adjusting the characteristics thereof is to preserve the user familiarity across postures110while optimizing graphical layouts (e.g., spacing between user interface elements210) and/or interaction patterns to accommodate for a current user input modality. In this way, the particular user interface elements210that users are already accustomed to selecting (or otherwise interacting with) to invoke certain functionalities remain available across different postures110of an operating system mode108(e.g., different postures of a “desktop” mode). At the same time, certain characteristics of these particular user interface elements210are optimally adjusted to accommodate the current manner in which a user can potentially interact with those user interface elements210(e.g., touchpad input if a peripheral keyboard is attached vs. touch-screen input if the peripheral keyboard is detached).

Here, operation of the touch-enabled computing device100remains intuitive in the sense that a user can still cause the operating system102to invoke particular functions by selecting the same user interface elements210which were present in the task bar216prior to the peripheral user input device118becoming unavailable. At the same time, the increased linear spacing between these user interface elements210improves an ability for individual ones of these user interface elements210to be selected via a touch screen (e.g., a capacitive sensing display). For example, since a curser element is no longer being rendered to indicate precisely which user interface element is being hovered over prior to a user clicking a button to complete the selection, the increased spacing reduces the probability of the user inadvertently selecting an icon that is adjacent to an intended or targeted icon.

FIG. 2Cillustrates an alternative scenario in which the touch-enabled computing device100transitions to operation in the second posture110(2) of the first mode108(1). As illustrated in scenario C, the touch-enabled computing device100has performed the posture adjustment to the second posture110(2) in response to detecting user input modality signals126that include a combination of the peripheral user input device118being currently disconnected from the touch-enabled computing device100, one or more inputs from a stylus pen220via the touchscreen114. Similar to scenario B, scenario C represents circumstances in which the user input modality signals126are indicative that the touchscreen114will be the currently preferred channel (e.g., mode) for providing user input.

FIG. 2Dillustrates a scenario in which the touch-enabled computing device100is operating in accordance with a third exemplary posture110(3) of the first mode108(1) (e.g., the “desktop” mode). Here, scenario C corresponds to the touch-enabled computing device100operating in an “Extended Desktop Posture” of the first mode108(1) (e.g., the “desktop” mode). As illustrated in scenario D, the touch-enabled computing device100has detected user input modality signals126that include a combination of the accelerometer data indicating that the touch-enabled computing device100is resting on a surface and is at a physical location that is in close proximity to another computing device230that is operating in “desktop mode” and/or to which both keyboard and optical mouse (or touchpad) user inputs are available. In response to these user input modality signals126, a posture adjustment is performed that includes: (i) determining a current operational state of the other computing device230, and (ii) dynamically reproducing aspects of the current operational state based on user input that is being received via other computing device230. For example, as illustrated, user interface elements210being rendered within a task bar of the other computing device230may be reproduced within the task bar of the touch-enabled computing device100.

Exemplary user input modality signals126for triggering such a posture adjustment include, but are not limited to, accelerometer data indicating that the touch-enabled computing device100has been gently “tapped” against the other computing device230just prior to being rested adjacent to the other computing device230(e.g., the gentle tap may serve an a que that the user intends to pair the two devices), gyroscope data indicating that an orientation of the touch-enabled computing device100matches an orientation of the other computing device230(e.g., the respective display screen angles match and/or are within a threshold range of matching), etc. Here, the posture adjustment of the touch-enabled computing device100into the third posture110(3) serves to compliment the use of the other computing device230by increasing the functionality of the other computing device230in some predefined manner. For example, aspects of the current operational state of the other computing device may be graphically reproduced so that the touch-enabled device duplicates or serves as an extension of the desktop of the other computing device. That is, the display area204of the device100may serve as an extended display area to a main display area of the other computing device230. In this way, a user who is currently using a first device (e.g., a laptop computer230) may seamlessly extend or duplicate the desktop thereof by tapping a second device (e.g., the touch-enabled computing device100) against the first device and then positioning the second device adjacent thereto.

FIG. 3illustrates an exemplary scenario300in which a user preference302is set within the user preference data104of the operating system102of the touch-enabled computing device100to extend applicability of touchpad gestures to the touchscreen114. As illustrated in scenario300, the user preference302is designed to prescribe whether or not a series of touchpad gestures that are defined within touchpad gesture data302are able to be provided to the touch-enabled computing device100via the touchscreen114. For purposes of the present discussion, presume that the user preference302is toggled from “No” to “Yes” at time T1to extend applicability of the touchpad gestures to the touchscreen114.

In some embodiments, the user preference data104includes both the touchpad gesture data302that defines the touchpad gestures and touchscreen gesture data304that defines a series of touchscreen gestures that by system default can be provided to the touch-enabled computing device100via the touchscreen114. Exemplary touchpad gestures include, but are not limited to, a “show desktop” gesture that is performed by placing three fingers on the touchpad120of the peripheral user input device118and swiping these three fingers toward oneself, a “see all open windows” gesture304that is performed by placing three fingers on the touchpad120and swiping these three fingers away from oneself, an “open digital assistant” gesture that is performed by tapping three fingers on the touchpad, and so on. Exemplary touchscreen gestures include, but are not limited to, a “zoom in” gesture that is performed by placing two fingers on the touchscreen114at a point of interest and then spreading the fingers apart, a “close app” gesture that is performed by swiping a finger from the top of the touchscreen to the bottom of the touchscreen, and so on.

As illustrated, at time T2a user308performs the “see all windows” gesture306that is defined within the touchpad gesture data304. Here, since the applicability of the touchpad gestures has been extended to the touchscreen114at time T1, the touch-enabled computing device100will respond to the touchpad gesture306being performed on the touchscreen114just the same as if the touchpad gesture306were to be performed on the touchpad120. Furthermore, if any touchscreen gesture that is defined within the touchscreen gesture data304corresponds to placing three fingers on the touchscreen114and swiping these three fingers away from oneself, the touch-enabled computing device100may opt to perform the action defined in association with the touchpad gesture306rather than another action associated with the touchscreen gesture based on the user preference that is set at time T1.

Turning now toFIG. 4, a flow diagram is shown for an exemplary process400for adjusting a posture of an operating system mode for a touch-enabled computing device based on combinations of user preferences and user input modality signals. It should be understood by those of ordinary skill in the art that the operations of the methods disclosed herein are not necessarily presented in any particular order and that performance of some or all of the operations in an alternative order(s) is possible and is contemplated. The operations have been presented in the demonstrated order for ease of description and illustration. Operations may be added, omitted, performed together, and/or performed simultaneously, without departing from the scope of the appended claims.

Thus, it should be appreciated that the logical operations described herein are implemented (1) as a sequence of computer implemented acts or program modules running on a computing system such as those described herein) and/or (2) as interconnected machine logic circuits or circuit modules within the computing system. The implementation is a matter of choice dependent on the performance and other requirements of the computing system. Accordingly, the logical operations may be implemented in software, in firmware, in special purpose digital logic, and any combination thereof.

At operation402of the routine400, a touch-enabled computing device receives operating system mode data that defines a first mode and a second mode for an operating system to operate in accordance with. For example, as described above, the touch-enabled computing device may be configured to operating in a desktop mode and a tablet mode. Moreover, the operating system mode data may further define at least a first posture and a second posture within which the touch-enabled computing device can operate the first mode in accordance with.

At operation404, the touch-enabled computing device executes the operating system in accordance with a first posture of the first mode. For example, while a peripheral user input device is coupled to the touch-enabled computing device, the operating system may operate in the first posture of the first computing mode.

At operation406, the touch-enabled computing device receives user preference data that indicates whether the operating system is to toggle from the first mode to the second mode in response to a predefined trigger event. For example, as described in relation toFIG. 1, user input may be received that defines a user preference not to have the operating system toggle into the second mode (e.g., tablet mode) in response to the predefined trigger event.

At operation408, the touch-enabled computing device monitors user input modality signals and, based thereon, identifies an occurrence of the predefined trigger event. For example, as described in relation toFIG. 2B, the touch-enabled computing device may determine that a peripheral user input device has been detached from the touch-enabled computing device. Additionally, or alternatively, the touch-enabled computing device may determine that accelerometer data is consistent with the device being held such that physical keyboard-based user inputs are unlikely.

At operation410, the touch-enabled computing device causes the operating system to respond to the occurrence of the predefined trigger event by performing a posture adjustment of the first mode from the first posture to a second posture of the first mode, based on the user preference data indicating that the operating system is not to toggle from operating in accordance with the first mode to operating in accordance with the second mode in response to the predefined trigger event.

It should be appreciated that the above-described subject matter may be implemented as a computer-controlled apparatus, a computer process, a computing system, or as an article of manufacture such as a computer-readable storage medium. The operations of the example methods are illustrated in individual blocks and summarized with reference to those blocks. The methods are illustrated as logical flows of blocks, each block of which can represent one or more operations that can be implemented in hardware, software, or a combination thereof. In the context of software, the operations represent computer-executable instructions stored on one or more computer-readable media that, when executed by one or more processors, enable the one or more processors to perform the recited operations.

Generally, computer-executable instructions include routines, programs, objects, modules, components, data structures, and the like that perform particular functions or implement particular abstract data types. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described operations can be executed in any order, combined in any order, subdivided into multiple sub-operations, and/or executed in parallel to implement the described processes. The described processes can be performed by resources associated with one or more device(s) such as one or more internal or external CPUs or GPUs, and/or one or more pieces of hardware logic such as field-programmable gate arrays (“FPGAs”), digital signal processors (“DSPs”), or other types of accelerators.

All of the methods and processes described above may be embodied in, and fully automated via, software code modules executed by one or more general purpose computers or processors. The code modules may be stored in any type of computer-readable storage medium or other computer storage device, such as those described below. Some or all of the methods may alternatively be embodied in specialized computer hardware, such as that described below.

FIG. 5illustrates a diagram that shows example components of an example device500(also referred to herein as a “computing device”) configured to generate data for some of the user interfaces disclosed herein.

As illustrated, the device500includes one or more data processing unit(s)502, computer-readable media504, and communication interface(s)506. The components of the device500are operatively connected, for example, via a bus509, which may include one or more of a system bus, a data bus, an address bus, a PCI bus, a Mini-PCI bus, and any variety of local, peripheral, and/or independent buses.

As utilized herein, the data processing unit(s)502may represent, for example, a CPU-type data processing unit, a GPU-type data processing unit, a field-programmable gate array (“FPGA”), another class of DSP, or other hardware logic components that may, in some instances, be driven by a CPU. For example, and without limitation, illustrative types of hardware logic components that may be utilized include Application-Specific Integrated Circuits (“ASICs”), Application-Specific Standard Products (“ASSPs”), System-on-a-Chip Systems (“SOCs”), Complex Programmable Logic Devices (“CPLDs”), etc.

As utilized herein, the computer-readable media504may store instructions executable by the data processing unit(s). The computer-readable media may also store instructions executable by external data processing units such as by an external CPU, an external GPU, and/or executable by an external accelerator, such as an FPGA type accelerator, a DSP type accelerator, or any other internal or external accelerator. In various examples, at least one CPU, GPU, and/or accelerator is incorporated in a computing device, while in some examples one or more of a CPU, GPU, and/or accelerator is external to a computing device.

Computer-readable media, which might also be referred to herein as a computer-readable medium, may include computer storage media and/or communication media. Computer storage media may include one or more of volatile memory, nonvolatile memory, and/or other persistent and/or auxiliary computer storage media, removable and non-removable computer storage media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or other data. Thus, computer storage media includes tangible and/or physical forms of media included in a device and/or hardware component that is part of a device or external to a device, including but not limited to random access memory (“RAM”), static random-access memory (“SRAM”), dynamic random-access memory (“DRAM”), phase change memory (“PCM”), read-only memory (“ROM”), erasable programmable read-only memory (“EPROM”), electrically erasable programmable read-only memory (“EEPROM”), flash memory, compact disc read-only memory (“CD-ROM”), digital versatile disks (“DVDs”), optical cards or other optical storage media, magnetic cassettes, magnetic tape, magnetic disk storage, magnetic cards or other magnetic storage devices or media, solid-state memory devices, storage arrays, network attached storage, storage area networks, hosted computer storage or any other storage memory, storage device, and/or storage medium that can be used to store and maintain information for access by a computing device.

In contrast to computer storage media, communication media may embody computer-readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave, or other transmission mechanism. As defined herein, computer storage media does not include communication media. That is, computer storage media does not include communications media consisting solely of a modulated data signal, a carrier wave, or a propagated signal, per se.

Communication interface(s)506may represent, for example, network interface controllers (“NICs”) or other types of transceiver devices to send and receive communications over a network. Furthermore, the communication interface(s)506may include one or more video cameras and/or audio devices522to enable generation of video feeds and/or still images, and so forth. Furthermore, the communication interface(s)506may include the Integrated User I/O Device(s)112.

In the illustrated example, computer-readable media504includes a data store508. In some examples, the data store508includes data storage such as a database, data warehouse, or other type of structured or unstructured data storage. In some examples, the data store508includes a corpus and/or a relational database with one or more tables, indices, stored procedures, and so forth to enable data access including one or more of hypertext markup language (“HTML”) tables, resource description framework (“RDF”) tables, web ontology language (“OWL”) tables, and/or extensible markup language (“XML”) tables, for example. The data store508may store data for the operations of processes, applications, components, and/or modules stored in computer-readable media504and/or executed by data processing unit(s)502and/or accelerator(s). For instance, in some examples, the data store508may store User Preference Data104(e.g., User Preference Data104as shown inFIG. 11), OS Mode data106(e.g., as also shown inFIG. 1), and/or other data.

Alternately, some or all of the above-referenced data can be stored on separate memories516on board one or more data processing unit(s)502such as a memory on board a CPU-type processor, a GPU-type processor, an FPGA-type accelerator, a DSP-type accelerator, and/or another accelerator. In this example, the computer-readable media504also includes an operating system518and application programming interface(s)510(APIs) configured to expose the functionality and the data of the device500to other devices.

Conclusion