Panorama:Plan
(As of June 2012, Panorama is being actively worked on by chlee, limi, and ttaubert - see bug 765422)
Now that Panorama is an integral part of Firefox, it becomes incumbent upon the team to really integrate Panorama into the Firefox ecosystem. We currently exist as a feature that is quietly on the fringe; a great benefit to power users, but limited in scope. We need to become more firmly a part of the browser, utilizing shared metaphors and functionality.
The major feature we've wanted but couldn't get to is what we've called All-Windows: making each Panorama window simply a view into the entire tab space of the app; each tab from every browser window would show up. This is a big change, and requires a good number of changes both in Panorama and in the browser. We'll focus on the necessary architectural changes first, and only then, once that's solid, change the front-end UI of the feature.
Contents
Tab Groups API
We'd like to separate the Tab Groups "model" layer from the Panorama "view" layer. This means that we'd like to create a solid API for grouping tabs that can both Panorama (our primary way of visualizing grouped tabs that will be included in Firefox) and add-on developers can build on.
Currently, Panorama is used by a very small population of Firefox users, primarily those who might be considered "power users". The UX team suspects that this is because the feature is too complicated for the average user. The user-experience core Panorama product will be simplified to be more usable for the average user, but the API should allow developers to develop add-ons that support tab group views with more control, hierarchy, or power.
Automatic Grid-Based Layout
On the UI side, Panorama will be simplified to automatically arrange groups in a grid-based layout rather than allowing (and requiring) users to drag and drop groups of any size anywhere on the canvas.
All-Windows
Internal tab group API will be implemented as a JavaScript module. We should split the code into multiple files for ease of development and combine them at build-time.
Global group storage
Following the proposal in Bug 588217 we continue to use session store as the tab group storage. As tab groups become window-independent we could just store them as "windows" (with type="set" or type="tab-group") in session store. All windows in SS are displayed as tab groups in Panorama. Windows without the property type="set" are actively displayed in a window (and get restored as a window when restarting). To make this work we need to update the SS service to allow the retrieval of all stored windows and to store new arbitrary windows with type="set" (tab groups). Additionally we need to be able to put a tab group into "closedWindows[]" when it is removed in Panorama.
As the state of our storage can obviously change after a private browsing mode switch or after session restore we need to reload the Panorama view (just as we currently do). We need to ask UX/UR folks what to do with groups when entering or leaving private browsing mode. What does Places do? Do they throw away all bookmarks?
The implementation can happen right before the All-Windows UI itself because we can provide a backwards compatible Panorama behavior with an additional window identifier attached to every group. So we can filter out groups that don't belong to the current window and revert that change once the UI is actually implemented.
Schema
{
windows: [
{ tabs: [{ url: "about:blank#1" }] },
{ tabs: [{ url: "about:blank#2" }], type: "set", extData: { panorama: "{bounds: {width: 200, height: 200}}" } }
],
closedWindows: [ { tabs: [{ url: "about:blank#3" }], type: "set" } ]
}
JS Module API
TabGroups void createGroup(string aTitle); TabGroup[] getAllGroups(); void removeGroup(TabGroup aGroup); TabGroup string getTitle(); void setTitle(string aTitle); string getData(); void setData(string aKey, string aData); Tab[] getChildren(); Tab getChild(int aIndex); void insertChild(Tab aTab, int aIndex); void removeChild(Tab aTab); Tab TabGroup getTabGroup(); <xul:tab> getXulTab(); string getData(); void setData(string aKey, string aData);
Group ~= Window
In addition, we'd like to simplify Panorama's hierarchy. The current version of Panorama allows users to organize tabs into tab groups and then organize tab groups into windows. Not only do we want to make all tab groups visible across all windows, but we want to model windows as viewports of groups.
This means that each window will necessarily be represented by a tab group. Each tab group does not necessarily need to be represented by a window; a group does not have to be open in a window.
All-Windows UI
Now that the underlying architecture is ready, we should change Panorama to be a view into the whole window-spanning tab space.
We need detachable tabs (or a similar solution) to move tabs between windows. Ideally the constraint for tabs to have a parent window can be removed. When a window gets closed when showing a specific tab group (that is marked as permanent, somehow) all contained tabs should be detached and the window be closed. If this tab group is now shown again in a new/other window the tabs are re-attached to it.
We should only allow one active Panorama view at a time. This saves resources and we don't need to synchronize multiple instances. When showing Panorama we just use nsIFrameLoaderOwner.swapFrameLoaders() to put the lazy-loaded frame into its place. When a second view gets shown we freeze/deactivate the first one.
With one data set shared between different windows we need to take care of the different possible window sizes and aspect ratios to make sure we don't destroy the groups layout every time the user opens Panorama in some other window. To keep the actual spatial layout we might need to scale until it fits.
UX Questions
- Does a group close when the displaying window is closed? Only untitled/unstarred groups?
- Unsure (leaning towards "no"), but potential issues and a way to distinguish between starred/unstarred are discussed here: feature page | mockup
- We should visually mark a group that is currently displayed in a window.
- What to do when opening a already shown group in another window? Show the group and show panorama in its old window? Just bring the other window to the top (don't forget about multi-display setups)?
- If group A is loaded in a window, opening the Panorama UI and clicking on group B should load group B's content into the current window and, if group B is loaded in another window, switch that window to show group A's content (or potentially the Panorama UI). Switching content out of windows instead of switching windows themselves allows the user to retain focus on the position on the screen where their window is.
- etc.
Browser Integration
Looking into the future, once Panorama's core functionality is stabilized, we can start entertaining other ideas about how to integrate other features of the browser into Panorama. Can we visualize things like bookmarks, history, and even downloads? What are other ways we can show basic browser functionality in Panorama. In what ways can we extend Panorama-like philosophies to other features?
Synchronization
We should provide the possibility to synchronize tab groups across multiple devices. Mobile devices could be represented as a designated tab group on desktop machines. This should aim to be at least a good replacement for about:sync-tabs.
Feature Page | Bug 652040 | Bug 589336 | Bug 590470
Bookmarks
With lazy-loaded reopening of tabs from previous sessions now being standard in Firefox, bookmarks are much more similar current tabs. We should think about how the models of Panorama tabs and bookmarks can be simplified. On the simplest level, there's no reason why Panorama shouldn't be able to visualize bookmarks in the same way it visualizes tabs (example). On a deeper level, the concepts of bookmarks and tabs could potentially be merged or at least rethought with respect to Panorama.
History
The visualization concept of Panorama can also be used to visualize history (though probably without the concept of groups). Note that as with bookmarks (though perhaps to a lesser degree), Panorama blurs the lines between current tabs and past tabs (history), which is also worth some thought. At the least, perhaps a way of indicating how recently pages visible in Panorama were visited might be interesting.
Private Browsing
We should consider how windows with private browsing enabled should be handled when windows become viewports of groups. Private browsing windows could be connected to a temporary group in the Panorama UI that disappears when closed, or they could just not appear in the Panorama UI at all.
Discoverability
Panorama button on toolbar
The Panorama button is not on the toolbar by default - it is automatically added if we see some pattern that indicates actual usage. This heuristic was added because the feature was considered incomplete and rather unstable at the time Firefox 4 was released. When we and release drivers are sure the feature is stable and useful for casual users we should put it on the toolbar by default again.
What are the criteria for Panorama being included in the primary UI?
Questions for (not only) UX/UR
- Where do people expect to find a feature like Panorama?
- People who aren't aware of Panorama, but need something like it... how do they find it?
- People who have heard about it need... how do they locate it?
- Why is this feature promoted as Panorama but is not called that in Firefox itself?
- Does "group your tabs" make more sense for people who aren't aware of it but might find it useful?
Feature completion
Search
t.b.d.
