Managing workspaces in a user interface
By presenting and managing multiple workspace images and application window groups in the user interface, the problem of desktop clutter in multi-window environments is solved, improving user work efficiency.
Patent Information
- Application Number
- CN202210913528.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Priority Date
- 2010-10-19
- Filing Date
- 2011-10-19
- Publication Date
- 2025-12-09
- Estimated Expiration
- 2031-10-19
AI Technical Summary
When multiple application windows are open simultaneously, users find it difficult to effectively manage and quickly identify application windows related to their organization, resulting in a cluttered desktop and impacting work efficiency.
By presenting multiple workspace images in the user interface, each workspace image corresponding to a virtual workspace, application windows are grouped into clusters that share common characteristics, and each space is represented by a thumbnail image, providing indicators of common characteristics, allowing users to select and manage these spaces through user input.
It enables effective management and rapid identification of application windows, reduces desktop clutter, and improves user efficiency in multitasking environments.
Smart Images

Figure CN115269094B_ABST
Abstract
Description
[0001] This application is a divisional application of the patent application No. 201180057800.1, filed on October 19, 2011, entitled "Managing Workspaces in a User Interface", having the same assignee herewith incorporated by reference in its entirety. TECHNICAL FIELD
[0002] The present disclosure relates generally to managing virtual workspaces on a computing device. BACKGROUND
[0003] Modern graphical user interfaces allow a large number of graphical objects or items to be displayed on a display screen at the same time. Leading personal computer operating systems, such as Apple Mac OS , provide user interfaces in which windows can be displayed, overlaid, resized, moved, configured, and reformatted as needed by the user or application. Taskbars, menus, virtual buttons, and other user interface components provide mechanisms for accessing and activating windows, even if those windows are hidden behind other windows.
[0004] As a result, most computers today are capable of running a large number of different programs. This can be achieved by the computer executing software code available locally to the computer or by connecting the computer to a remote application server (e.g., over the Internet). Examples of application programs include business-related software (e.g., record management programs and meeting organization programs), software optionally used for business or personal use (e.g., word processors or e-mail applications), and software primarily used for personal use (e.g., online chat or music file management programs).
[0005] Due to the large number of different applications available, users are encouraged to use a large number of items in their computers to work. Certain categories of items, such as a certain type of file, can be restricted to use by a particular application program, while other categories of items can be compatible with several programs. Depending on the needs of the user, he or she can need to use several different programs within a limited time period as part of a daily work routine or in order to accomplish a particular goal. As a result, the user can sometimes have several windows open on the computer display at the same time.
[0006] However, due to the large number of windows open at the same time, the desktop can become cluttered and difficult to overview. As a result, the user can have difficulty finding a particular application when needed. Also, the large number of windows and running applications can be difficult to organize and manage effectively. For example, the user can have difficulty in quickly identifying application windows that are related to each other. In some cases, the user can have multiple workspaces, each having a different configuration of graphical objects and application windows. The user can need to quickly move from one workspace to the next while also being able to dynamically change the workspaces when needed. SUMMARY
[0007] In a first general aspect, a method for managing virtual workspaces is disclosed. A plurality of workspace images is presented in a user interface, each corresponding to a different virtual workspace available to a user in a computer system. A user input is received, the user input indicating a selection of a presented workspace image. The user interface is updated to display a plurality of application windows associated with the selected virtual workspace. The displayed application windows are visually grouped into one or more clusters, each corresponding to one or more application windows sharing a common characteristic.
[0008] Implementations can include any or all of the following features. The common characteristic shared by the at least one cluster of application windows is that the application windows are different instances of the same application. The common characteristic shared by the at least one cluster of application windows can also be that the application windows are instances of different applications that share at least a common functionality. The common functionality of different applications in a given cluster includes at least one of: word processing, email, web browsing, file browsing, system utilities, spreadsheet manipulation, drawing, digital photo manipulation, system utilities, and instant messaging. The method can further include displaying a common characteristic indicator for each cluster. The common characteristic indicator can include a visual representation representing an identity of an application of the common characteristic. The common characteristic indicator can also include a visual representation representing a functionality of the common characteristic. Each of the plurality of clusters is displayed such that any window of any cluster does not overlap any other window of any other cluster.
[0009] In a second general aspect, a computer program product tangibly embodied in a computer readable storage medium includes instructions that, when executed, generate a graphical user interface for presenting virtual workspaces on a display device and perform the following operations. A plurality of workspace images is presented in a user interface, each corresponding to a different virtual workspace available to a user in a computer system. A user input is received, the user input indicating a selection of a presented workspace image. The user interface is updated to display a plurality of application windows associated with the selected virtual workspace. The displayed application windows are visually grouped into one or more clusters, each corresponding to one or more application windows sharing a common characteristic.
[0010] Implementations can include any or all of the following features. A common characteristic shared by the at least one group of application windows is that the application windows are different instances of the same application. A common characteristic shared by the at least one group of application windows can also be that the application windows are instances of different applications that at least share a common functionality. The common functionality of different applications in a given group includes at least one of: word processing, email, web browsing, file browsing, system utilities, spreadsheet manipulation, drawing, digital photo manipulation, system utilities, and instant messaging. The method can also include displaying a common characteristic indicator for each group. The common characteristic indicator can include a visual representation of an identification of an application that represents the common characteristic. The common characteristic indicator can also include a visual representation of a functionality that represents the common characteristic. Each of the plurality of groups is displayed such that any window of any group does not overlap any other window of any other group.
[0011] Details of one or more implementations of managing multiple items in a user interface are described in the accompanying drawings and description below. Other features, aspects, and advantages will become apparent from the description, the drawings, and the claims. BRIEF DESCRIPTION OF DRAWINGS
[0012] Figure 1 An example user interface showing a bridge interface for viewing and managing virtual workspaces is illustrated.
[0013] Figure 2A An example user interface showing workspace image reordering is illustrated.
[0014] Figure 2B An example user interface showing transitioning from one active workspace to another different workspace while in a bridge interface is illustrated.
[0015] Figure 2C An example user interface showing changes in a workspace associated with an application window is illustrated.
[0016] Figure 2D An example user interface showing creating a new workspace with an appropriate drag-and-drop action is illustrated.
[0017] Figures 3A-3D An example action performed on a group of application windows is illustrated.
[0018] Figure 4 An example user interface showing creating a new virtual workspace is illustrated.
[0019] Figure 5 A flow diagram of an example process for displaying a bridge view of workspaces in a user interface.
[0020] Figure 6This is a flowchart of an exemplary process for changing the virtual workspace associated with an application window.
[0021] Figure 7 This is a flowchart illustrating an exemplary process for changing from one active workspace to a different active workspace.
[0022] Figure 8 This is a flowchart of an exemplary process for expanding an application window group.
[0023] Figures 9A-9C Examples are provided for implementing references. Figures 1-8 An exemplary software architecture for the bridge interface processing described above.
[0024] Figure 10 It is used to implement reference Figures 1-9C A block diagram describing the user interface and an exemplary hardware architecture for the processing.
[0025] Similar labels in each diagram indicate similar components. Detailed Implementation
[0026] Overview
[0027] Computing systems such as personal computers, handheld devices, smartphones, gaming devices, and portable computers typically include hardware components such as processing units (e.g., one or more processors), memory, and various input and output devices (e.g., displays, keyboards, mice, touch-sensitive surfaces). A software operating system (O / S) can be installed on the computing system and executed through the processing unit to control the operation of the computing system.
[0028] Many operating systems and software applications employ graphical user interfaces (GUIs) to present information to users and receive user input for controlling the behavior and functionality of underlying computing devices and / or applications. A typical two-dimensional GUI of an operating system can be likened to a "desktop."
[0029] Visually, the operating system desktop can provide a background (e.g., the desktop plane) that can display other graphical objects, such as icons representing connected peripherals (e.g., disk drives, network devices, printers, etc.), installed programs, stored documents, open windows of running applications, file system folders, etc. Additionally, user interface components that allow users to interact with certain aspects of the operating system can also be displayed in different locations on the desktop. For example, a three-dimensional menu bar showing basic controls of the desktop environment, a system tray showing background running programs, and a docking station for shortcuts to frequently used applications can also be displayed on the desktop plane.
[0030] Operating systems of computing devices can typically support a large number of active applications at the same time, and each active application can have multiple open windows that are simultaneously presented on a desktop plane. A user can switch between active applications and open windows by selecting (e.g., clicking on) the window that he / she wishes to access. Once selected, the selected open window can gain input focus and become the current active window (or "topmost window") of the desktop. The user can interact with the active window in the manner dictated by the application that provided the current active window.
[0031] Windows, icons, application components, taskbars, and other graphical items currently displayed on the desktop are in some cases components that the user has recently used or plans to use. As the number of application windows and graphical objects displayed on the desktop increases, a user can prefer to associate certain application windows with one another. For example, a user can prefer to group application windows that relate to the same task or that have been or will be used within the same time frame.
[0032] In some implementations, these graphical objects can be grouped into one or more virtual workspaces, or "spaces." As used herein, a space is a grouping of one or more applications or windows (relative to other applications or windows) such that the programs / applications of a single space are visible when that space is active and such that a view of all spaces and their contents can be generated. Each space can depict a different desktop layout, including application windows, desktop images, icons, or other graphical objects that are displayed only when that associated space is active. A user can focus a view of the windows in a particular selected space such that those windows are enlarged or brought forward in the GUI relative to the windows in unselected spaces. An application can have more than one window in a space, or an application can have windows in more than one space, just to name a few examples.
[0033] A bridge interface of the GUI can present an overview of the spaces currently available to the user to allow the user to efficiently manage the different spaces. As used herein, a bridge view or bridge interface can be a display in the user interface of multiple virtual workspaces concurrently with at least some of the application windows associated with one of the virtual workspaces. Thumbnail images can be displayed to represent each of the spaces, the thumbnail images providing a condensed representation of the appearance of each space as in an activated state. In some implementations, each thumbnail image is a real-time depiction of the state of the application windows associated with the space represented by the thumbnail image. A user can navigate and select the thumbnail images with different user inputs to activate a particular space. In the bridge interface, the activated space includes an organized format of the application windows associated with that space to allow the user to quickly identify and access application windows that share common characteristics.
[0034] Example user interface for viewing and managing desktops in a user interface
[0035] Figure 1 An example user interface 100 is illustrated, which can be a desktop of an operating system. The two-dimensional desktop plane has an appearance that is substantially coplanar or parallel to the display surface of the underlying hardware screen. When an application executing in the operating system environment generates a new window, the window can be displayed on the topmost layer of the two-dimensional desktop plane. In this example, the user interface 100 can include applications and desktops rendered in the space of the bridge view 100. The depiction includes components and spatial components that can be found in a graphical user interface display, as this example includes a dock 130 for displaying available applications, a group of open application windows (120, 122, 124, 126, 128), a system space such as a dashboard 104 or a calendar 112, and several individual spaces (106, 108, 110) arranged in a row of thumbnails 103, each of which represents a different space. The dashboard can be an application for hosting small applications called window widgets. In some implementations, the dashboard can be a semi-transparent layer that is not visible to the user unless the dashboard is activated (e.g., by clicking on the icon). When the dashboard is activated, the user's desktop darkens and the window widgets are presented in the foreground. The window widgets can be moved around, rearranged, deleted, and recreated. In some implementations, the dashboard window widgets can be HTML files displayed within the dashboard.
[0036] A toolbar provided by an application or the operating system can be shown on the display of the computer. In some implementations, the toolbar is hidden from view during the display of the bridge view 100. The toolbar can include items such as menus, icons, and objects that provide information. Some menus can be generic and not specific to a particular application, such as a file menu. Other menus can be application dependent, such as a terminal menu, in which case they can be added to or removed from the toolbar depending on whether the corresponding application window is active. In general, an "active application window" refers to a program window that is designated as the primary recipient of user input for an input device, such as a keyboard, touchpad, or touch screen. The user or a component such as the operating system can cause different program windows to be designated as the active program window within each given space. Icons can be used to present information to the user, such as status information, and / or can be used to access functionality, such as through a pop-up menu or a command to open another application window. The display can also include a dock component 130, which provides an area from which commonly used or preferred applications can be easily accessed by selecting an icon included in the dock component 130, where each icon is associated with a different application.
[0037] A computer monitor with multiple spaces is shown, including a first space 106, a second space 108, and a third space 110. In the bridge view shown, these spaces are arranged in rows 103 near the top of the monitor, each space representing a portion of a larger desktop that can be scaled to show, for example, more detail. In some implementations, the row 103 of spaces can be arranged in different formats and at different locations on the screen. For example, the spaces in row 103 can be grouped differently based on whether the space is a system space (such as dashboard 104) or a user-defined space. For example, system spaces can be displayed together in row 103, while user-defined spaces can be displayed adjacent to system spaces. Each space is represented in the bridge view by a simplified representation of the application windows open within that space. In the example shown, space 106 is represented by a visual workspace image 106 or a thumbnail image of a miniaturized depiction of application windows open within space row 103. In zoom mode, individual spaces can be active and presented at a larger size, while application windows contained in other spaces are hidden or only partially visible. "Active" space refers to a selected space where its components are easily accessible and visible to the user. When a particular space is active, visual components associated with other spaces can be hidden and invisible. These spaces represent a larger desktop surface than the desktop that can be simultaneously displayed on the monitor. Therefore, application windows are depicted at a reduced size to allow all or most active windows to be displayed within that space.
[0038] In some implementations, a space can be dedicated to a specific application or an arrangement of multiple applications. For example, such as Figure 1 As depicted, a space can serve as dashboard 104 for commonly used applications such as weather forecasts, clocks, calculators, or other applications designated as dashboard applications. The space can also be dedicated to other uses, such as a calendar or schedule, represented by space 112.
[0039] Each space can also be associated with a specific image, such as desktop wallpaper 170. Desktop wallpaper 170 serves as the image displayed in the background of the desktop interface. Therefore, in addition to being associated with a set of open application windows, each space can also be associated with specific display settings (such as a specific desktop image displayed in the background when that space is active). In this case, each space acts as its own desktop, and users can personalize each space by determining the background image, the application windows being used, or other settings for that specific space according to their preferences.
[0040] One or more application windows can be arranged in a variety of ways within a space. Application windows can be positioned such that they overlap each other completely or partially. They can be resized or moved around in the space to accommodate the user. In particular, although many windows can be open and distributed among the spaces at the same time, in some implementations only the application windows in a particular space are visible when that space is active. In some cases, a program or window from another space that is not currently active can be visible. For example, in Figure 1 In the depicted bridge view 100, all available spaces can be shown in an organized arrangement such as a row of spaces 103. In other cases, a smaller representation of another space can be visible on the display away from the bridge view to achieve a "picture-in-picture" effect. In some cases, an application or window can be briefly presented even if its space is not displayed; for example, certain events such as the completion of a task can cause a program window to be presented for a limited time or until the user dismisses the window.
[0041] When a space is active, the application windows of the active space revert to their initial positions prior to entering the bridge view 100. In some implementations, the display can exit the bridge view 100 and only present the contents of the active space. The background image associated with the space is displayed as the desktop wallpaper. When the bridge view 100 is displayed, the application windows for a space are grouped or clustered together in the available area of the screen. In some cases, each window grouping includes all application windows or application instances associated with a particular application for a particular desktop. Also, each window grouping can be described as an application window "cluster." The grouping of windows can also be based on other shared characteristics, such as windows associated with different applications but functionally similar. For example, several web browser windows can be open in a particular space. If the space is activated, the windows within the space are enlarged as if they were dragged to the front of the display. The individual web browser windows in the space can be grouped together in an area of the screen to form a web browser window cluster. Each window cluster can be associated with an icon that indicates the particular application associated with the windows in a certain window cluster. Thus, a user can identify the type of windows found in a particular window cluster based on the icon displayed in the area of the particular window cluster. Still further, a user can optionally select application windows to group together as a cluster regardless of whether the application windows share a common characteristic or are associated with the same application.
[0042] In the illustrated example, space 106 is currently selected. As in Figure 1As seen in FIG. 1, each application window grouping (120, 122, 124, 126, 128) associated with space 106 is depicted in the selected desktop for space 106. Moreover, each application window grouping can include open application windows for a particular application or that share a common characteristic. For example, application windows associated with a web browser can be grouped together in a cluster 128, and an icon 128a can be displayed proximate to cluster 128 to allow a user to quickly determine that the application windows in cluster 128 are associated with a web browser application. A separate icon 128b associated with the web browser application can be depicted in the dock 130 to make it simple to open an additional window for the web browser application. Similarly, each cluster (e.g., clusters 120, 122, 124, and 126) in space 106 is associated with a different application. In some implementations, the clusters are displayed such that the windows of any cluster do not overlap any other windows of a different cluster. As Figure 1 As depicted in FIG. 1, each cluster is a grouping of application windows associated with a particular application that a user can select from the dock 130. Dock 130 includes an icon (120b, 122b, 124b, 126b, 128b, 180, 190) for each application available to the user. In some implementations, dock 130 is displayed in the user interface regardless of the currently active space, which allows a user to navigate dock 130 without losing the selected space.
[0043] Each window group can contain windows that have been reduced in size to group windows associated with the same application together in the same area of the GUI. In some implementations, the application windows in all groups are reduced in size by the same scaling factor to maintain the relative proportions of these spaces. If a particular group has been activated, or if a specific window within the group is selected, the window can expand to a larger size. If multiple windows are grouped in a group, they can be arranged in a particular order, such as in a cascading or overlapping layout. In some implementations, a sorting algorithm can be used to determine the particular order of the window layout in a group. For example, the sorting algorithm can use various heuristics, settings, user preferences, or other parameters to determine the order in which windows are arranged in a group. The parameters used by the sorting algorithm can include, for example, the size associated with each window, the type of window, how recently the window has been accessed relative to other windows in the group, how identifiable a portion of the window is, experience data related to user preferences, and other factors used to determine the appropriate layout of windows in a group. Also, within each group, windows can be arranged so that the highest priority window is displayed through the most prominent area compared to lower priority windows. The priority of each window can depend on various factors, such as how recently the window has been accessed by the user. For example, in a group with multiple application windows, a particular window that the user has most recently interacted with (e.g., clicked) can be designated as the active window in the group. In some implementations, the windows in a group are grouped together in an area of the GUI without necessarily being stacked or overlapping. Window groups can be grouped in a particular area based at least in part on where the windows were located in the GUI prior to being grouped.
[0044] Figure 1The bridge view shown allows users to view available spaces and select which space to use. In some implementations, users can enter or exit the bridge view using specific user inputs (such as keyboard input, specific gestures on a touchpad, selection using an input device such as a mouse, or any other appropriate user input). While in bridge view mode, applications can continue to run and program windows can be displayed normally, for example, at a smaller scale. Program windows can continue to update, for example, displaying animations, refreshing their content, etc. The continuous updating of application windows can be shown through both the thumbnail images in row 103 and the group of windows in bridge view 100. In a sense, bridge view 100 mode provides the user with a visual overview of all spaces and the applications and visual settings within each space. Users can navigate between spaces using appropriate user inputs (such as via mouse, keyboard hotkeys, key combinations, gestures, or other mechanisms). Other devices can also be used for input, such as those used to provide alternative input capabilities for users with disabilities. Users can zoom in on subsets of spaces. In one implementation, the system can automatically switch from one space to another based on predetermined events, such as when a specific application is launched or when an application produces specific output.
[0045] Exemplary actions for managing space in a bridge view
[0046] Figure 2A-2D Screenshots 200, 250, 280, and 290 depict different actions performed on the space in the bridge view. For example, as... Figure 2A As shown, the spaces in bridge 203 can be rearranged by the user or automatically by a computer application. In the example shown, these spaces are initially arranged in a specific order: dashboard space 204 is on the far left, followed by first space 206, second space 208, third space 210, and calendar application 212 is on the far right. Optionally, the user can rearrange the order of these spaces using appropriate user input. For example, the user can use a mouse or touchpad to perform a drag-and-drop action to reposition the spaces displayed in thumbnail row 203. Many operating systems enable drag-and-drop operations on currently selected items in the GUI. In a drag-and-drop operation, the representation of the selected item can follow the movement of a pointer (e.g., a mouse cursor or a clicking device on a touch-sensitive surface) to move (or “drag”) from one area of the GUI to another within the user interface. When these items are released (or “dropped”) onto the drop area of the desired target area, the selected item becomes a content item in that desired target area.
[0047] In the illustrated example, the user can drag and drop the space 208 from one location and insert the space into a different area, such as between different spaces around it. In some implementations, however, some spaces can be movable while some spaces are fixed. For example, a particular desktop such as space 206 can be designated as a default space and remain fixed in thumbnail row 203. As seen in Figure 2A Space 208 can be extracted from its original location between spaces 206 and 210 and further inserted to the right between spaces 210 and 212, as seen in FIG. 2B. As the user drags the row 203 of spaces, a pointer or other input indicator that slides over a particular space thumbnail can trigger an animation that temporarily enlarges the space thumbnail to allow the user to more closely observe the contents of the space while the surrounding spaces shrink in size to accommodate the temporary enlargement. If the space is moved to a new location that has already been occupied by another space, the other space can be automatically repositioned to make room for the moved space. Moreover, the repositioned space or one or more other spaces can adjust to fill the vacated space location. In some implementations, the animation of rearranging space 208 can include space 208 being dragged away from its initial location by a cursor controlled by the user, following the cursor as it moves to a different area on the screen, and detaching from the depiction of the cursor somewhere on the screen after the user enters an input such as releasing a button on the input device. Here, space 208 is moved between spaces 210 and 212 while space 210 shifts to the left to occupy the original location of space 208 in row 203. The user can also specify a preferred way to handle space movement.
[0048] Other operations can be performed on spaces, such as renaming a particular space or selecting a new wallpaper for a space, for example.
[0049] Figure 2B An example screenshot is illustrated that transitions from one active space to another different active space. In some implementations, the user can activate a first space and then seamlessly transition from the first space to a newly activated second space. For example, when the user activates a space (such as space 206 in Figure 2B
[0050] A user can select a different space (e.g., space 210) to activate with an appropriate input. In some cases, the user can select space 210 to activate by clicking on the image representing space 210 in thumbnail row 203 using a cursor or a finger on a touch screen, entering a particular input on a keyboard, or using a particular gesture of the user's finger on a multi-touch input device. The particular gesture can include, for example, a flick of the user's finger on the multi-touch input device. The user's selection to activate space 210 causes the deactivation of space 206 prior to activating workspace 270 associated with space 210. The transition can be depicted by any appropriate animation. For example, as shown in Figure 2B FIG. 6, the transition can be depicted as the workspaces sliding on the screen. The animation can include the newly activated workspace 270 including the desktop wallpaper and application group associated with the selected space 210 sliding onto the screen from the right, and the deactivating workspace 260 sliding off the screen to the left. The direction of the sliding workspaces can correspond to the relative positions of the spaces in thumbnail row 203. In the present example, the newly activated space 210 is positioned to the right of the previous space 206, so the sliding motion of workspaces 260 and 270 is from right to left.
[0051] The switching from one space to an adjacent space can be accomplished using different gestures on a multi-touch input device. In some implementations, a user can perform a flick gesture on a multi-touch input device in a right-to-left direction to switch the currently active space to the space represented by the thumbnail image to the right of the thumbnail representing the currently active space. Alternatively, a user can perform a flick gesture from left to right to switch the currently active space to the space represented by the thumbnail image to the left of the thumbnail representing the currently active space.
[0052] Further, as seen in Figure 2B the newly activated space 210 is represented by a thumbnail adjacent to the previous space 206. Thus, the animation includes a direct transition from one workspace 260 to another workspace 270. In some implementations, a sliding animation can also be used for transitions between two spaces in thumbnail row 203 that are not adjacent to each other, such as a direct transition from space 208 to space 210. In such a case, some details from the desktop of the space between the two spaces can be included in the animation to depict the spatial relationship between the spaces and the switching from one active space to another. Thus, the transition from space 208 to space 210 in the illustrated example can include an animation showing the details of space 206 sliding across the entire screen between the animation of space 208 sliding off the screen and space 210 sliding onto the screen.
[0053] Figure 2CAnother example action that can be performed during the management of desktop spaces is depicted. A user can create a space with an initial layout of application windows, icons, or desktop wallpaper. The user can then change the content or appearance of the space with various inputs. For example, a user can move an application window or an entire group of windows from one space to another, or associate the application window with a different space. This change can be initiated by the user, for example, because the application window is to be used in conjunction with an application already present in another space. In the example shown, the currently active space 206 can include a particular application window 282 that the user wants to move to a different space 210. The user can select the application window 282 and, with an appropriate gesture such as a drag-and-drop operation, transfer the application window 282 to a different space 210 by dropping the application window 282 on the thumbnail image representing the space 210. The application window 282 selected by the user can be a single application window, multiple application windows from the same group, or an entire group of application windows. In some implementations, a new instance of the window is created in the space 210 as window 284, while in other cases a copy of the application window is formed in the space 210, while the original window 282 remains in the space 206. While the above example describes a single application window being moved, other movements are possible in some implementations. For example, all windows of a type, all windows of a single application, or a selected set of windows can be moved. In some implementations, some changes to a space, such as moving content from one space to another, can be made in the bridge view or zoomed-in mode.
[0054] Figure 2D An example of creating a new space with an appropriate input such as a drag-and-drop operation is depicted. In the bridge view 290, a user can select the application window 282 and drag-and-drop the application window to a position 292 between the two other spaces 208 and 210. In some implementations, this operation automatically triggers the creation of a new space containing the application window 282, and the thumbnail image of the new space is located at the position 292 between the spaces 208 and 210.
[0055] A user can use a menu, icon, pop-up menu, gesture, hot key, or key combination to signal his or her intent to transfer an application window. In some implementations, the application window to be moved can be selected via a mouse click or gesture, a combination of button presses such as a tab or arrow, or a combination thereof. Various methods can be used to move an application window, such as dragging the application window from its source space with a mouse and dropping it into the destination space, or repositioning the application window into the destination space with keyboard commands.
[0056] Example actions for managing windows in a group
[0057] Figures 3A-3DExample actions for managing cluster application windows in a bridge view are depicted. As described above in connection with Figure 1 application windows that share at least one common characteristic can be grouped together in a cluster 300 based on that common characteristic. Each cluster can include application windows from the same space that share a common characteristic. However, in some implementations, a user can also link application windows from other spaces that share the same characteristic. In some implementations, the individual application windows in a particular cluster represent different instances of the same application. Alternatively, the individual application windows in a particular cluster can represent instances of different applications that share at least one common functionality. For example, application windows associated with different applications that share a common functionality (e.g., word processing, email, web browsing, file browsing, system utilities, spreadsheet manipulation, drawing, digital photo manipulation, system utilities, or instant messaging) can be grouped together in a cluster even though the application windows represent instances of different applications.
[0058] As shown in Figure 3A application windows 302, 304, 306, and 308 can be grouped together in close proximity to one another. The grouped application windows can be currently open windows in the respective space, or can be windows that represent recently closed windows and display an image of the last known appearance of the closed windows. In some cases, the application windows are visually presented as a stack of overlapping windows, each overlapping window having a different associated z-depth, while in other cases the application windows are in close proximity but not overlapping. The particular layout of the application windows in a cluster can be based on a variety of factors, such as user preference, conventions of the user community, visibility of different windows, or other potential factors. In Figure 3A application windows 302, 304, 306, and 308 are visually presented as a stack of overlapping windows in the cluster. In some implementations, the individual application windows can be centered.
[0059] Figure 3A The application windows in can also be displayed with a visual indicator 310 of the common characteristic that the application windows in cluster 300 share. In some cases, the visual indicator 310 is an icon 310 that depicts a visual representation of the common characteristic associated with cluster 300. For example, if the common characteristic of the application windows in cluster 300 is that they are all instances of a particular web browser application, a standard icon typically used to represent a web browser application can be used here as the common characteristic indicator 310. If the common characteristic of the application windows is a common functionality, such as application windows associated with performing photo editing, an icon 310 of a camera can be used to indicate that the application windows in the cluster relate to photo editing.
[0060] The user can perform one or more actions to expand the group of application windows 300 so that the application windows are more visible to the user. In some implementations, the user can click on the indicator 310 with a pointer 312 associated with an input device to expand the application windows in the group 300 as illustrated in Figure 3B After the user performs the action to expand the group 300, the application windows 302, 304, 306, and 308 can be visually displaced in a radial direction away from a center point to which the center of the application windows was previously aligned so that the user can view the contents of the application windows. Also, the size of some or all of the application windows can increase as the application windows move away from the group 300. In some cases, the application windows of the group 300 that have been expanded can cover the application windows in other groups that have not been expanded. Also, the application windows in other groups can be "de-emphasized" by being displaced toward the edge of the GUI or dimmed relative to the group that is currently being expanded.
[0061] In some implementations, the application windows are expanded from the center point of the group 300 in one step so that the application windows transition from their overlapping positions as seen in Figure 3A to their respective separate positions as seen in Figure 3C The application windows of a group can be displayed in an expanded mode so that the windows of the group do not overlap any of the other windows of the group as seen in Figure 3C In some cases, the size of the application windows can be reduced to enable the application windows to be displayed in this non-overlapping manner.
[0062] The application windows can also be displaced away from the center of the group 300 in an incremental manner so that after each increment, each application window is more visible to the user as seen in Figure 3B In some implementations, the user can enter successive iterations of input to enable the application windows in the group 300 to be separated in an incremental manner, with the application windows gradually expanding in a radial direction with each increment. In some cases, the user can not want to fully expand the application windows, but can only want to get a glimpse of the contents of the application windows in the group as depicted in Figure 3B The user can enter an appropriate input, such as hovering a cursor over the group or entering a slight gesture or movement around the group, to effectively move the application windows slightly apart from each other, creating the impression that the user is pushing the group of application windows. In some implementations, the user can also identify a particular window from the group of windows to be displayed in its entirety in the GUI. For example, the user can directly click on the title bar of the application window to separate the application window from the group to allow the user to view the full window.
[0063] Different types of user input can be used to enable visual manipulation of application windows in a group 300. User input associated with a cursor, such as a drag-and-drop operation, can be used to enable visual movement of these application windows. In another example, a user can also gradually expand application windows in a group by hovering a cursor associated with a mouse or touchpad, or a finger in conjunction with a multi-point touch input device, over the application windows in the group. For example, a user can also utilize a scrolling motion of a user's finger to expand application windows. Expansion of these windows can be based on the speed or repetition of the user's scrolling. For example, an upward scrolling motion of a finger can trigger expansion of application windows in a group, while a downward scrolling motion can trigger contraction of application windows in the group. In a further example, on a multi-point touch input device or touch screen, a user can use two fingers in contact with the input device to simulate an expansion motion with the tips of the user's fingers. As the user's fingers move apart from a central position where the fingers are close to each other to an expanded position, the application windows in the group are proportionally spread apart from the fingers.
[0064] Figure 3D are combined in a group or reverse the above-described expansion of application windows. Figure 3B A visual depiction of the action of expanding application windows is described above. When a different group is selected for expansion or when a different space is activated, application windows 302, 304, 306, and 308 can automatically contract back into a group. However, in some cases, a user can initiate contraction of these application windows into a compact grouping using input similar to that described above. Figure 3B For example, a user can move cursor 312 to click on common features indicator 310 or other areas of the user interface to enable contraction of application windows. These application windows are then displaced inward from their original positions toward a center point to enable overlap of a portion of the application windows. Also, application windows in a group can automatically contract in response to a user selection to expand application windows in a different group.
[0065] An example action for creating a new desktop space
[0066] Figure 4An example configuration for creating a new desktop space is illustrated. For example, a user can generate a new space with appropriate user input, such as by clicking or selecting an icon 410 displayed on the desktop or typing a particular input on a keyboard or entering a gesture on a multi-touch input device. In some implementations, a new thumbnail image representing the new space 414 can be automatically created after the user selects to create a new space. Also, a configuration tool 420 can be displayed to provide the user with the option to input a name 422, theme 424, or wallpaper 426 for the new desktop space 414. A new desktop space can also be automatically created when an application launches into full screen mode, the user selects full screen mode from within an application, or the user creates a new application window.
[0067] A new desktop space can also be configured at creation without the configuration tool 420. For example, if a particular application window is already open in a different space, the user can access the application window and explicitly mark the window for insertion into the newly created space 414. The user can also drag and drop the application window onto the thumbnail image representing the new space 414 to include the window in the new space 414.
[0068] Example process for presenting a bridge view of a desktop space in a user interface
[0069] Figure 5 is a flowchart of an example process 500 for displaying a bridge view of a desktop space in a user interface. In the example process 500, workspace images are presented in a user interface (510). The workspace images can be images corresponding to different virtual workspaces available to a user of a computer system. For example, the workspace images can be thumbnail images depicting a condensed real-time snapshot of application windows, desktop configurations, and other graphical objects presented in each virtual workspace. The various thumbnail images displayed in the user interface can correspond to different virtual workspaces.
[0070] A virtual workspace can be conceptualized using the metaphor of a "desktop," and as such, the virtual workspace is a desktop space, or simply a space. User input is received to indicate a selection of a presented workspace image (520). A user can select a particular workspace image to activate the space represented by the image. In some implementations, a plurality of workspace images are presented to a user, allowing the user to navigate the images and select a particular image to access the contents of the space associated with the image. User input to select a particular space can include, for example, clicking on a workspace image associated with the particular space with a cursor, a keyboard input, or a predetermined gesture with a multi-touch input device.
[0071] After a workspace image is selected, the application windows associated with the selected workspace are grouped into clusters based on a shared common characteristic of the application windows in each cluster (530). The shared common characteristic of the application windows in a cluster can be the same application associated with the windows in the cluster. In some cases, application windows that are instances of different applications but share a common functionality can be grouped together as a particular cluster.
[0072] The user interface is updated to display the application windows associated with the selected workspace as visually grouped clusters (540). Each cluster of application windows can be visually delineated such that the user can effectively distinguish the application windows associated with different shared characteristics. For example, the application windows in each cluster can be delineated in a manner that is visually close to one another and separate from the application windows of other clusters.
[0073] Figure 6 is a flowchart of an example process 600 for changing a virtual workspace associated with an application window. A virtual workspace associated with a workspace image can be activated and displayed to a user, the display including a presentation of one or more application windows. If the user selects at least one application window in the displayed virtual workspace (610), the user can drag the selected application window to a new location (620). If the new location coincides with a workspace image different from the workspace image associated with the displayed virtual workspace (630), the virtual workspace associated with the selected application window is changed to correspond to a virtual workspace associated with the different workspace image (640).
[0074] Figure 7 is a flowchart of an example process 700 for changing from an active workspace to a different workspace. An active workspace can be presented to a user in a user interface. The user can perform an input that matches a predetermined gesture (720). If the user's input matches the predetermined gesture, the change from the current active workspace to another workspace (730).
[0075] Figure 8is a flowchart of an example process 800 for spreading out a group of application windows. Multiple application windows can be grouped together in a group based on sharing a common characteristic. The group can be initially depicted in the user interface as a set of application windows in close proximity to each other, some of which can overlap. Appropriate user input is received to separate the application windows in the group (810). If the received user input indicates selection of the displayed group (820), the user interface is updated to display the application windows of the selected group such that any window does not overlap any other window (830). If one or more application windows are too large after updating the user interface to avoid overlap (840), the size of one or more application windows of the selected group can be reduced to cause the application windows to not overlap.
[0076] The above processes are merely examples, and various combinations of the above processes are possible.
[0077] Example software architecture
[0078] Figure 9A is an example software architecture 900 for implementing the processes and user interfaces described with reference to Figures 1-8 In some implementations, the program modules implementing these processes can be part of a framework of a software architecture or stack. The example software stack 900 can include an application layer 902, a framework layer 904, a services layer 906, an OS layer 908, and a hardware layer 910. Applications (e.g., email, word processing, text messaging, etc.) can incorporate function hooks into the accessibility API. The framework layer 904 can include a bridge view UI modification engine 912. The bridge view UI modification engine 912 can make API calls to graphics services or libraries in the services layer 906 or the OS layer 908 to perform all or some of the tasks described with reference to Figures 1-8 The bridge view UI modification engine 912 can also make API calls to the application layer 902 to obtain information necessary to define the virtual workspace thumbnail image and to determine the location and content of the thumbnail image of the virtual workspace according to the descriptions disclosed in this specification. The bridge view UI modification engine 912 can also make API calls to services or libraries (e.g., text services) in the services layer 906 or the OS layer 908 to perform all or some of their tasks.
[0079] The service layer 906 can provide various graphics, animations, and UI services to support the graphics functionality of the bridge view UI modification engine 912 and applications in the application layer 902. In some implementations, the service layer 906 can also include a touch model for interpreting raw touch data from a touch sensitive device and mapping it to touch events (e.g., gestures, swipes), which can be accessed by applications using a call convention defined in a touch model API. The service layer 906 can also include a communication software stack for wireless communication.
[0080] The OS layer 908 can be a full operating system (e.g., MAC OS) or a kernel (e.g., UNIX kernel). The hardware layer 910 includes hardware necessary to perform the tasks described with reference to the Figures 1-8 The hardware layer 910 includes hardware necessary to perform the tasks described with reference to the
[0081] In some implementations, one or more application programming interfaces (APIs) can be used. An API is an interface implemented by a program code component or hardware component (hereinafter "API-implementing component") that allows a different program code component or hardware component (hereinafter "API-calling component") to access and use one or more services or functions provided by the API-implementing component. An API can define one or more parameters that are to be passed as input to the API-implementing component, in the form in which they are to be input. An API can be a source code interface that a user uses to access a framework provided by an operating system or middleware.
[0082] An API allows a developer (which can be a third party developer) of the API-calling component to leverage specified features provided by the API-implementing component without the developer having to "reinvent the wheel" by having detailed knowledge of the underlying logic and functionality of the API-implementing component. There can be one API-calling component, or there can be more than one such component. An API can be a source code interface that a computer system or program library provides in order to support requests for services from an application. An operating system can have a number of APIs to allow applications running on the OS to call one or more of the APIs, and a service (such as a program library) can have a number of APIs to allow an application that uses the service to call one or more of the APIs. An API can be specified in terms of a programming language that can be interpreted or compiled when an application is built, or the API can be specified in terms of a scripting language that can be interpreted at run-time.
[0083] In some implementations, an API implementation component can provide more than one API, each providing a different view of or having different aspects of access to the functionality implemented by the API implementation component. For example, one API of an API implementation component can provide a first set of functionality and can be exposed to third party developers, while another API of the API implementation component can be hidden (not exposed) and provide a subset of the first set of functionality and also provide another set of functionality, such as testing or debugging functionality not in the first set of functionality. In other implementations, the API implementation component itself can call one or more other components via underlying APIs and thus be both an API calling component and an API implementation component.
[0084] An API defines the language and parameters with which an API calling component uses when accessing and using the prescribed features of an API implementation component. For example, an API calling component accesses the prescribed features of an API implementation component by one or more API calls (e.g., embodied by function or method invocations) exposed by the API and invoking the API with parameters passing data and control information. In response to an API call from an API calling component, an API implementation component can return a value via the API. While an API defines the syntax and results of API calls (e.g., how to invoke an API call and what the API call does), the API can not reveal how the functionality embodied by an API call is implemented by the API implementation component. Various API calls are communicated between the calling (API calling component) and the API implementation component via one or more application programming interfaces. Communicating an API call can include publishing, issuing, invoking, calling, triggering, receiving, returning, or responding to a function call or message; in other words, communicating can describe an action that is performed by an API calling component or an API implementation component. A function call or other invocation of an API can send or receive one or more parameters via a parameter list or other structure. A parameter can be a constant, a key, a data structure, an object, an object class, a variable, a data type, a pointer, an array, a list, or a pointer to a function or method or other means to reference data or other items to be passed via the API.
[0085] Further, data types or classes can be provided by an API and implemented by an API implementation component. Thus, an API calling component can declare variables, use pointers to variables, use constant values of such types or classes by using the definitions provided in the API.
[0086] In general, an API can be used to access a service or data provided by an API- implementing component or to initiate performance of an operation or computation provided by an API- implementing component. As an example, an API-implementing component and an API-calling component can each be any one of an operating system, a library, a device driver, an API, an application, or other module (it should be understood that an API-implementing component and an API-calling component can be the same or different type of module); it should be understood that an API-implementing component and an API-calling component can be on the same or different computing devices. In some cases, an API-implementing component can be implemented in, for example, the form of a firmware, microcode, or other hardware logic. In some implementations, an API can allow a client program to use services provided by a software development kit (SDK) library. In other implementations, an application or other client program can use an API provided by an application framework. In these implementations, the application or client program can incorporate calls to functions or methods provided by the SDK and provided by the API, or use data types or objects defined in the SDK and used by the API. In these implementations, the application framework can provide a main event loop for the program that responds to various events defined by the framework. The API allows the application to specify events and respond to those events using the application framework. In some implementations, an API call can report to an application the capabilities or status of a hardware device, including those related to input capabilities and status, output capabilities and status, processing capabilities, power status, storage capabilities and status, communication capabilities, and the like, and the API can be implemented in part by firmware, microcode, or other low-level logic executing in part on a hardware component.
[0087] An API-calling component can be a local component (i.e., on the same data processing system as the API-implementing component) or a remote component (i.e., on a different data processing system from the API-implementing component) that communicates over a network with the API-implementing component via the API. As should be appreciated, an API-implementing component can also function as an API-calling component (i.e., it can make API calls to APIs exposed by a different API-implementing component), and an API-calling component can also function as an API-implementing component by implementing APIs exposed to differing API-calling components.
[0088] An API can allow multiple API-calling components, written in different programming languages, to communicate with a single API-implementing component (i.e., the API can include features for translating calls and returns between the API-implementing component and the API-calling components); however, the API can be implemented in a specific programming language. In one embodiment, an API-calling component can call APIs from different providers such as one set of APIs from an OS provider and another set of APIs from a plug-in provider and another set of APIs from another provider such as a software development kit (SDK) provider or creator of the other set of APIs.
[0089] Figure 9Bis a block diagram 920 illustrating an example API architecture that can be used in the implementation of some of the processes and user interface variations disclosed herein. As shown in Figure 9B The API architecture 920 includes an API implementing component 922 (e.g., an operating system, a library, a device driver, an API, an application program, software, or other module) that implements an API 924, as shown in
[0090] It should be recognized that the API implementing component 922 can include additional functions, methods, classes, data structures, and / or other features that are not specified by the API 924 and are not available to the API calling component 926. It should be understood that the API calling component 926 can be on the same system as the API implementing component 922 or can be located remotely and access the API implementing component 922 over a network using the API 924. Although Figure 9B A single API calling component 926 is illustrated as interacting with the API 924, but it should be understood that other API calling components, written in a different language (or the same language) than the API calling component 926, can also use the API 924.
[0091] The API implementing component 922, the API 924, and the API calling component 926 can be stored in a machine-readable medium, including any mechanism for storing information in a form readable by a machine (e.g., a computer or other data processing system). For example, a machine-readable medium includes magnetic disks, optical disks, random access memory, read only memory, flash memory devices, etc.
[0092] In Figure 9CThe middle ("software stack" 930) illustrates an example implementation in which an application can make calls to service A 932 or service B 934 using several service APIs (service API A and service API B) and make calls to an operating system (OS) 936 using several OS APIs. Service A 932 and service B 934 can make calls to the OS 936 using several OS APIs.
[0093] Note that service B 934 has two APIs, one of which (service B API A 938) receives calls from and returns values to application A 940, and the other of which (service B API B 942) receives calls from and returns values to application B 944. Service A 932, which can be, for example, a software library, makes calls to and receives return values from OS API A 946, and service B 934, which can be, for example, a software library, makes calls to and receives return values from both OS API A 946 and OS API B 948. Application B 944 makes calls to and receives return values from OS API B 948.
[0094] Example device architecture
[0095] Figure 10 is an example hardware architecture 1000 of a device that implements the processing and interface of the bridge view of the virtual workspace described in reference to Figure 1 FIG. 1 is a block diagram of an example hardware architecture 1000 of a device that implements the processing and interface of the bridge view of the virtual workspace described in reference to FIG. 9. The device can include a memory interface 1002, one or more data processors, image processors, and / or processors 1004, and a peripheral interface 1006. The memory interface 1002, the one or more processors 1004, and / or the peripheral interface 1006 can be independent components or can be integrated in one or more integrated circuits. For example, the various components in the device can be coupled by one or more communication buses or signal lines.
[0096] Sensors, devices, and subsystems can be coupled to the peripheral interface 1006 to facilitate a variety of functionality. For example, a motion sensor 1010, a light sensor 1012, and a proximity sensor 1014 can be coupled to the peripheral interface 1006 to facilitate orientation, lighting, and proximity functionality of the mobile device. A position processor 1015 (e.g., a GPS receiver) can be connected to the peripheral interface 1006 to provide geopositioning. An electronic magnetometer 1016 (e.g., an integrated circuit chip) can also be connected to the peripheral interface 1006 to provide data that can be used to determine the direction of magnetic north. Thus, the electronic magnetometer 1016 can be used as an electronic compass. An accelerometer 1017 can also be connected to the peripheral interface 1006 to provide data that can be used to determine the speed and direction changes of the mobile device.
[0097] A camera subsystem 1020 and an optical sensor 1022, e.g., a charged coupled device (CCD) or a complementary metal-oxide semiconductor (CMOS) optical sensor, can be utilized to facilitate camera functions, such as recording photos and video clips.
[0098] Communication functions can be facilitated through one or more wireless communication subsystems 1024, which can include radio frequency receivers and transmitters and / or optical (e.g., infrared) receivers and transmitters. The specific design and implementation of the communication subsystem 1024 can depend on the communication network(s) with which the mobile device is intended to operate. For example, a mobile device can include communication subsystems 1024 designed to operate with a GSM network, a GPRS network, an EDGE network, a Wi-Fi or WiMax network, and a Bluetooth network. In particular, the wireless communication subsystem 1024 can include a hosting protocol enabling the mobile device to be used as a base station for other wireless devices.
[0099] An audio subsystem 1026 can be coupled to a speaker 1029 and a microphone 1030 to facilitate voice-enabled functions, such as voice recognition, voice replication, digital recording, and telephony functions.
[0100] The I / O subsystem 1040 can include a touch screen controller 1042 and / or other input controller(s) 1044. The touch screen controller 1042 can be coupled to a touch screen 1046 or touch pad. The touch screen 1046 and the touch screen controller 1042 can, for example, detect contact and movement or break thereof using any of a plurality of touch sensitivity technologies, including but not limited to capacitive, resistive, infrared, and surface acoustic wave technologies, as well as other proximity sensor arrays or other components.
[0101] The other input controller(s) 1044 can be coupled to other input / control devices 1048, such as one or more buttons, rocker switches, thumbwheel, infrared port, USB port, and / or a pointing device, e.g., a stylus. The one or more buttons (not shown) can include an up / down button for volume control of the speaker 1028 and / or the microphone 1030.
[0102] In one implementation, a first duration of button press can unlock the touch screen 1046; and a second duration of button press, longer than the first duration, can turn the power to the device on or off. The user can be able to customize one or more of the button(s) and / or the touch screen 1046 to include a personalized icon of the user's choice. The touch screen 1046 can also be used to implement virtual or soft buttons and / or a keyboard.
[0103] In some implementations, the device can present recorded audio and / or video files, such as MP3, AAC, and MPEG files. In some implementations, the device can include the functionality of an MP3 player, such as an iPod TM ). Accordingly, the device can include a pin connector that is compatible with the iPod. Other input / output and control devices can also be used.
[0104] The memory interface 1002 can be coupled to the memory 1050. The memory 1050 can include high-speed random access memory and / or non-volatile, computer-readable storage media (e.g., one or more disk storage devices, one or more optical storage devices, and / or flash storage). The memory 1050 can store operating system 1052, such as Darwin, RTXC, LINUX, UNIX, OS X, WINDOWS, or an embedded operating system such as VxWorks. The operating system 1052 can include instructions for handling basic
[0105] The memory 1050 can also store communication instructions 1054 to facilitate communicating with one or more additional devices, one or more computers and / or one or more servers. The memory 1050 can include graphical user interface instructions 1056 to facilitate graphic user interface processing; sensor processing instructions 1058 to facilitate sensor-related processing and functions; phone instructions 1060 to facilitate phone-related processes and functions; electronic message instructions 1062 to facilitate electronic-messaging related processes and functions; web browsing instructions 1064 to facilitate web browsing-related processes and functions; media processing instructions 1066 to facilitate
[0106] The instructions listed above, and each of the applications, can correspond to a set of instructions for performing one or more of the functions described above. These instructions need not be implemented as separate software programs, procedures, or modules. Memory 1050 can include additional instructions or fewer instructions. Furthermore, various functions of the mobile device can be implemented in hardware and / or in software, including in one or more signal processing and / or application specific integrated circuits.
[0107] The described features can be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. The features can be implemented in a computer program product tangibly embodied in an information carrier, e.g., in a machine-readable storage device for execution by a programmable processor; and method steps can be performed by a programmable processor executing a program of instructions to perform functions of the described implementations by operating on input data and generating output. The described features can be implemented advantageously in one or more computer programs that are executable on a programmable system including at least one programmable processor coupled to receive data and instructions from, and to transmit data and instructions to, a data storage system, at least one input device, and at least one output device. A computer program is a set of instructions that can be used directly or indirectly in a computer to perform a specified activity or bring about a specified result. Programs of instructions can be written in any form of programming language, including compiled or interpreted languages, and they can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.
[0108] The described features can be implemented advantageously in one or more computer programs that are executable on a programmable system including at least one programmable processor coupled to receive data and instructions from, and to transmit data and instructions to, a data storage system, at least one input device, and at least one output device. A computer program is a set of instructions that can be used directly or indirectly in a computer to perform a specified activity or bring about a specified result. Programs of instructions can be written in any form of programming language, including compiled or interpreted languages, and they can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.
[0109] As examples, suitable processors for the execution of a program of instructions include, a general and special purpose microprocessors, and the sole processor or one of multiple processors or cores, of any type of computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both, the elements of a computer. The essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or input to, or in
[0110] To provide for interaction with a user, the features can be implemented on a computer having a display device such as a CRT (cathode ray tube) or LCD (liquid crystal display) monitor for displaying information to the user and a keyboard, a mouse, or a trackball, or a pointing device (e.g., a finger or a stylus on a touch-sensitive screen or touch-sensitive display) by which the user can provide input to the computer.
[0111] The features can be implemented in a computer system that includes a back- end component, such as a data server, or that includes a middleware component, such as an application server or an Internet server, or that includes a front-end component, such as a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation, or any combination of these, or in any other computer system.
[0112] The components of the system can be connected by any form or medium of digital data communication such as a communication network. Examples of communication networks include, e.g., a LAN, a WAN, and the computers and networks comprising the Internet.
[0113] The one or more features or steps disclosed herein can be implemented using an API. An API can define one or more parameters that are passed between an calling application and another software code (e.g., an operating system, a library routine, a function) that provides a service, provides data, or performs an operation or computation.
[0114] An API can be implemented as one or more calls implemented by a parameter list or other structure in program code. Parameters can be constants, key values, data structures, objects, object classes, variables, data types, pointers, arrays, lists, or another call. An API call and parameters can be implemented in any programming language. A programming language can define the vocabulary and calling convention by which a programmer writing a call will interact with functions provided by another software code.
[0115] In some implementations, an API call can report to an application the capabilities of a device running the application, such as input capabilities, output capabilities, processing capabilities, power capabilities, communication capabilities, and the like.
[0116] A number of implementations have been described. Nevertheless, it will be understood that various modifications can be made. For example, elements of one or more implementations can be combined, deleted, modified, or supplemented to form further implementations. As another example, the logic flows depicted in the figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In addition, other steps can be provided, or steps can be eliminated, from the described flows, and other components can be added to, or removed from, the described systems. Accordingly, other implementations are within the scope of the following claims.
Claims
1. A method comprising: At a computer system having a display and one or more input devices: A user interface for managing a virtual workspace is displayed on the monitor, wherein displaying the user interface includes simultaneously displaying: A representation of one or more virtual workspaces displayed in a first area of the user interface for managing virtual workspaces, the one or more virtual workspaces including a first virtual workspace; and The representation of a plurality of application windows associated with the first virtual workspace, including the representation of the first application window, wherein the representation of the plurality of application windows associated with the first virtual workspace is displayed in a second area different from the first area of the user interface for managing the virtual workspace; When the user interface for managing the virtual workspace is displayed, user input via the one or more input devices is detected, which instructs the representation of a first application window in the representation of the plurality of application windows to move from the second area to a position outside the representation of the one or more virtual workspaces in the first area; as well as In response to the detection of the user input, a second virtual workspace is created and a representation of the second virtual workspace, including a representation of the first application window, is displayed in the first area, wherein the second virtual workspace is the new virtual workspace.
2. The method of claim 1, wherein the user input includes dragging a representation of the first application window from the second region to a location outside the representation of the one or more virtual workspaces in the first region.
3. The method of claim 1, wherein the user input includes touch input, mouse input, or keyboard input.
4. The method according to claim 1, further comprising: In response to the detection of the user input, the first application window is de-associated with the first virtual workspace.
5. The method according to claim 1, further comprising: In response to the detection of the user input, the display of the first application window in the second area is stopped.
6. The method according to claim 1, further comprising: In response to the detection of the user input, the display of the representation of the first application window in the representation of the first virtual workspace in the first region is stopped.
7. The method according to claim 1, further comprising: In response to the detection of the user input, the association between the first application window and the first virtual workspace is maintained.
8. The method according to claim 1, wherein: The one or more virtual workspaces may also include a third virtual workspace; The representation of the one or more virtual workspaces displayed in the first area includes a representation of the first virtual workspace and a representation of the third virtual workspace adjacent to the first virtual workspace; The location outside the one or more virtual workspaces in the first region is the space between the representation of the first virtual workspace and the representation of the third virtual workspace; and The representation of the second virtual workspace is displayed in the first area between the representation of the first virtual workspace and the representation of the third virtual workspace.
9. The method according to claim 1, further comprising: When the user interface for managing virtual workspaces is displayed, a second user input via the one or more input devices is detected, the second user input instructing a representation of a first application window in the representation of the plurality of application windows to move from a second region to a position within a representation of the one or more virtual workspaces in the first region, the one representation of the one or more virtual workspaces corresponding to a corresponding virtual workspace in the one or more virtual workspaces that is different from the first virtual workspace; and In response to the detection of a second user input, a first application window is added to the corresponding virtual workspace and a representation of the first application window is displayed in the representation of the corresponding virtual workspace.
10. A computer system, comprising: monitor; One or more input devices; and One or more processors are configured to perform the method according to any one of claims 1 to 9.
11. A non-transitory computer-readable storage medium storing instructions that, when executed by a computer system having a display and one or more input devices, cause the computer system to perform the method according to any one of claims 1 to 9.
Citation Information
Patent Citations
Method and apparatus for providing a three-dimensional task gallery computer interface
US7512902B2