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.

It is with respect to these considerations and others that the disclosure made herein is presented.

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.

This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. The term “techniques,” for instance, may refer to system(s), method(s), computer-executable instructions, module(s), algorithms, hardware logic, and/or operation(s) as permitted by the context described above and throughout the document.

