TaskSwitching

Task switching

How should you switch between:

  • tabs within in a window?
    • windows? (both recently-used, and long-ago used)
      • applications? (is it necessary at all?)
        • workspaces?

What other OSes do

Windows Vista

(Summary video)

  • There is no standard keyboard equivalent for switching tabs in a window that has them, though (Shift+)Ctrl+Tab is fairly common.
  • Clicking in a visible part of a window switches to it, and does whatever clicking in that part of the window would normally do. (There are occasional exceptions; for example, clicking in an Excel window switches to it and does nothing else.) This requires that part of the window be visible, which is rare because windows are often maximized.
  • Each window has a button in the Taskbar. Mousing over each button shows a thumbnail of the window. If many windows are open, windows belonging to the same program are collapsed into a single button that opens a menu listing the program’s windows.

  • Alt+Tab(+Tab(...)) switches between windows, most recently focused first, using a temporary translucent panel to show thumbnails of each.
  • Windows+Tab(+Tab(...)) (“Flip 3D”), available only in some Vista editions and for some graphics cards, switches between windows in the order they were opened, presenting them as a stack of overlapping sheets at a jaunty angle in the middle of the screen.
  • There is no built-in multiple-workspace feature.

Good: Alt+Tab is efficient for frequently switching between two windows. Understandable animated transition to/from Flip 3D.

Bad: Poor random access to large numbers of windows. Alt+Tab and Windows+Tab fulfil exactly the same task in different ways. Not obvious how a window jumps from the front to the back of Flip 3D. Up to three representations of a window on screen at the same time (actual window, taskbar button, and taskbar button thumbnail).

Mac OS X

  • There is no standard keyboard equivalent for switching tabs in a window that has them, though it is usually advertised in the application’s “Window” menu.

  • Clicking in a visible part of a window switches to it ― traditionally without also doing whatever clicking in that part of the window would normally do, though exceptions to this are becoming more common. This requires that part of the window be visible (which is somewhat more common than in Windows or Ubuntu, because maximizing is rare).

  • All applications have a “Window” menu, which lists all the application’s windows, along with a “Bring All to Front” item (and “Minimize” and “Zoom” items for the current window). (Shift+)Command+`(+`(+...)) cycles through the application’s windows in the order they were opened, though this is not advertised in the menu.

  • The application menu contains “Hide <app name>” (Command+H), “Hide Others” (Option+Command+H), and “Show All” items. Hiding the current application switches to the application that was next most recently active (regardless of whether it has any windows open).

  • (Shift+)Command+Tab(+Tab(...)) switches between whole applications, most recently focused first, using a temporary translucent panel to show large icons of each. Switching to an application this way brings all of its windows to the front, regardless of previous interleaving. Clicking the Dock icons of open applications works exactly the same as the application switcher (indeed the Dock functioned as the application switcher until 10.3).

  • Exposé zooms all windows (F9 by default) or those in the current application (F10 by default) into non-overlapping miniatures, where they can be selected using the mouse or arrow keys. Exposé can also be activated using screen hot corners.

  • Dashboard shows and hides (F12 by default) HTML+JavaScript “widgets” in a separate layer of windows (unlike the omnipresent Windows Vista Sidebar). Programs can’t be moved from the normal layer to the Dashboard, or (except for development purposes) from Dashboard to the normal layer.

  • Spaces shows multiple workspaces as sections of an overall plane. Applications can be set to always open on a particular workspace. Workspaces can be switched using Ctrl+ arrow keys, or accessed directly using configurable shortcuts (F1, F2, etc by default). The plane can be zoomed out (F8 by default) to show all workspaces; in this view, windows or even entire workspaces can be dragged to rearrange them. The all-workspaces view and Exposé can be used simultaneously.

Good: Only one representation of a window on screen at any time. Exposé provides easy and understandable random access.

Bad: Holy crap, that’s a lot of different ways to switch between windows. Dashboard and Spaces can look like applications in the Dock, but function essentially as switchers (for example, there’s no sensible reason for Spaces to appear as an application while Exposé doesn’t). Dashboard is useful only for programs that happen to be implemented as widgets, or that have a widget equivalent, an arbitrary and wasteful distinction. Exposé works poorly when there are too many windows open to see any distinguishing features.

Design considerations

  • To save screen space on subnotebooks, we want Ubuntu to have only one panel by default. This means either not having a top panel, or not having a taskbar.
  • A window-switching interface that works well without a taskbar could be used regardless of screen size.
  • Having multiple representations on screen simultaneously is needlessly confusing. With the graphic power of the computers Ubuntu runs on, there is no excuse for it, either: any small representation used for selection can be the real window, temporarily shrunken.
  • Rapid switching between recently-used windows is important, but random access to any window is also useful.
  • The Windows and Mac OS task switching interfaces have grown haphazardly over 25 years, contributing to their complexity and inconsistency (especially in Mac OS). Whatever we do, it should be simpler and more consistent.
  • The past 25 years have also shown that many tasks that used to be “applications” have partly or completely disappeared into the operating environment. Launching of other applications (Windows 3.0 “Program Manager” replaced by Windows 95’s Start menu, Mac OS 7.5 “Launcher” replaced by Mac OS X’s Dock), file management (Windows 3.0 “File Manager” replaced by Windows Explorer, Gnome Nautilus now accessed almost solely from the “Places” menu), FTP (in Windows and Ubuntu done mostly by the file manager), file CD burning (ditto), Internet connection (Mac OS X “Internet Connect”, replaced by the Network preference pane), search (Mac OS 8.5 Sherlock, replaced by Spotlight and Dashboard), accessibility aids (now controlled mostly from system settings windows), and to some extent even backup (standalone backup tools replaced in Mac OS X 10.5 by Time Machine) have all followed this trajectory. It is also becoming less common for tasks to involve multiple primary windows from the same application. (A palette should not be a primary window, so switching to a document window should bring along all palettes associated with it.) Therefore, switching between entire applications is not something that needs to be available by default; switching between windows is sufficient.

Proposals

Integration of full-screen, window switching, and workspace switching

We should define a visual continuum:

full-screen.jpg

full-screen view for one window

normal.jpg

normal view

windows.jpg

window switcher for this workspace

workspaces.jpg

workspace switcher

workspaces-windows.jpg

window switcher for all workspaces.

(For people using only one workspace, the last two items don’t apply.)

There should be “zoom in” and “zoom out” keyboard combos that take you in either direction along this continuum. (These are placeholder names; the final names probably should not refer to “zoom”, because that has a document-specific meaning in many applications.)

Full-screen view should replace maximized view. This means all (resizable) applications will have a full-screen view, instead of the current awkwardness of some applications having it and others not. An application should be able to tell when a window is in full-screen view, so that it can also remove toolbars etc as appropriate. But this will no longer involve a custom “Full Screen” (or “Fullscreen”) menu item, so applications should be encouraged/patched to remove it and any help mentioning it. (In Opera, “Full Screen” actually means “Presentation Mode”, so it should be renamed rather than removed.)

When in full-screen view or in normal view, Alt+Tab and Shift+Alt+Tab should behave as they normally do in Ubuntu and Windows, temporarily zooming out to the window-switcher. In the workspace switcher, (Shift+)Alt+Tab should switch between workspaces. In the window switcher for all workspaces, (Shift+)Alt+Tab should switch between all windows regardless of workspace.

Window switching

window-switcher.jpg

The window switcher should work like a tag cloud, but for recency rather than popularity: the most recently used windows should appear largest, with more neglected windows appearing smaller and further away.

Alt+Tab should navigate through this graphical window switcher, without making Alt+Tab slower. So if you’re switching to the second-most-recently-used window, returning to normal display should be instant. And even in other cases, keypresses should work even during the return-from-switcher animation.

Tab switching

Tab switching should be integrated with window switching by making tabs a feature of the window manager, rather than of individual programs.

This would solve many other problems, too:

  • Tabs would be available in any multi-window program (e.g. Nautilus, Abiword, Inkscape), not just in those programs whose developers had implemented it themselves.

  • Tabs would look and work exactly the same in every program.
  • Even windows of different programs could be tabbed together, if desired.
  • The interface (and code) of programs that had previously implemented a tabbed interface would become simpler, as they would no longer need tab-related menu items or preferences.
  • The visual illogic of tab-switching altering elements both above (e.g. the title bar) and below the tabs would be resolved, because the tabs would be segments of the title bar, above everything else.

  • The danger of a single close button closing dozens of tabs simultaneously would no longer be present, because the title bar would contain a close button for each tab, rather than one for all tabs.
  • The window switcher would be able to present all tabs of all windows simultaneously (solving the problem of finding a Web page amongst multiple tabbed windows, for example).

Windows could be tabbed together by dragging one onto another using the middle mouse button (or while using a modifier key), and could be rearranged or separated the same way.

Once you had tabbed together two or more windows of a program, the window manager would assume you wanted to tab together any future windows of the same program, until you manipulated them otherwise. This memory would persist across sessions.

The window switcher could present tabs of the same window side by side.

This work might need to wait until after 2010, both because it would rely on a rock-solid implementation of the window switcher, and because it would require invasive changes to the default Web browser, gnome-terminal, and other default applications that have implemented an internal tabbed interface.

Unresolved issues

  • If we get rid of the taskbar, where do minimized windows go? Perhaps the window switcher should be the only means of accessing them? This might be scary for people who minimized a window by mistake and now can’t see it.
  • If we get rid of the taskbar, how should windows attract attention?
  • If we have a global menu bar, should that be shown when in full-screen view? Probably. (Remember, full screen view should remain distinct from any Presentation or Slide Show view.)

MatthewPaulThomas/TaskSwitching (last edited 2008-08-06 16:23:12 by localhost)