Tabbed Windows Extension Discussion
- 1 Opening tabs and windows
- 2 Managing tabs
- 3 Other known problems and questions
Opening tabs and windows
Should we have one window with tabs or should we have several windows and should all of them have tabs?
OpenOffice.org has a lot of places where nowadays a new window is created or the existing one is replaced with new content (depending on the current content and the new content). In an application supporting tabs we could convert all of them to create a new tab instead of a new window. As this can be done in a central place of the code it is comparably easy to achieve and in fact it's the approach we took for our demo extension. (For developers: these are the cases where the target "_default" is used.)
On the other hand we already have some places in the code where always a new window is created, e.g. the help window, the preview windows of our wizards or a database form. These new windows are created for a reason and so we can't change this behavior. Our demo extension leaves them untouched, e.g. it still creates a new top window in these cases. (For developers: these are the cases where the target "_blank" or any non-reserved target name is used.)
So the question is not whether we will have one or more windows but whether users should be able to create new windows deliberately and if all windows should have tabs.
Some windows shouldn't have tabs at all. These are all windows that must have a fixed size, e.g.:
- database forms
- windows opened by OLE1 outplace editing
Also windows that are part of a workflow (like preview windows in a wizard) shouldn't have tabs.
An interesting question is whether the help window should support tabs but in this case it should only contain tabs showing help content. This is something that needs explicit support inside of the help GUI component.
How should users tell OpenOffice.org that they want to open a new window?
The most famous "tabbed" application, Firefox, has solved this problem by using a modifier key of the keyboard to customize the action triggered by a mouse click. But even this simplistic approach is limited: there are still places in Firefox where the user can't customize the behavior and so always ends up with the default behavior of replacing the current window content. An example is the "Open File" function. As a workaround Firefox offers commands to create new blank tabs or windows so that users can get their content opened in a new window or tab in a two-step process.
How can we apply this approach OOo? It's no option to double all menu entries that open windows nowadays (e.g. have "Open" and "Open in new window") as this will surely create too much clutter. Most documents in OOo are not opened by clicking on a hyperlink so that the "modifier key" pattern is not very useful for us. The "New Window"/"New Tab" approach is doable. It would create a new window or tab containing our so called "start module". It would need some work in the code as currently OOo assumes that there is only one such module instantiated in a running instance and it is a clear indication that no other window is open. The question remains how this is judged from a "user experience" POV: does it look strange? Or does it fit nicely into the tabbed document interface idea?
The best approach seems to be to stay with the solution in the demo component (each created document view creates a new tab except for the special cases) and add an "Open new window" command to the file menu. Actually such command better suits the "Window" menu but people might be used to look for it in the file menu (that's open for debate).
Should tabs become grouped by application?
Some users will want exactly this: keep all Writer documents as tabs in one window, all Calc documents in another etc. IMHO this is a very limited approach and also its implementation is very complicated as usually the type of a document is not always known when we have to create a window for it.
By grouping all documents in a window and leaving it up to the user to create a new window we give users the full power to arrange their tabs as they want without limiting them too much by default. And we save a lot of working time that can be invested elsewhere.
So to make the answer clear: no, tabs shouldn't be grouped by application. Grouping should be completely up to the user. All tabs hould go to the same window until the user explicitly has created a new one.
Do we need the ability to show more than one tab content at a time?
In short words: yes. It's a must-have for an Office application to be able to have at least two windows of either the same or different documents beneath or above each other.
This is where our biggest problems start. Currently our code is not able to place docked tool windows outside of the document view window so that in case of two presentation document tabs in one window that shall be shown in parallel we have two slide panes and two task panes eating up all the screen space or a permanent flickering when the focus is moved between the windows because the two panes of one window go while the two panes of the other one appear. What we want is having the panes outside the document view, *shared* between the two document windows or at least having each pair of windows taking the same screen space and so replacing each other as seemlessly as possible.
So some preliminary work needs to be done that enables us to place the docked tool windows outside the document view window as we already can do with toolbars. We have planned and designed some work for this.
Should users be allowed to reorganize tabs?
Of course. The tab order should be allowed to change and users should be able to drag a tab from one window to another.
Here's an example how we did it in the former StarOffice 5.2 (sorry, only German version available):
The second screen shot shows how two document windows united in one tab window share all their tool bars and windows.
Users should also be able to create a new window from a tab.
Other known problems and questions
With tabs it no longer makes sense to store window sizes per application; OTOH this could be a relief as this features already creates some problems.
Existing tabs in OpenOffice.org
Calc already uses tabs to organize its sheets. Together with additional tabs for documents this can become confusing for users. In Impress the tabs can at least become an optical problem as Impress documents also have tabs for the different kinds of views.
Positioning the tab bar
The prototype shows the bar at the bottom of the windows as in e.g. the Windows desktop. Firefox users have their bar of tabs at the top of the windows, below the toolbars. We could choose one or the other option or make it an option for the user. As having an option is not too much work we should do it. The option should be available in the context menu of the tab bar.
Does not work with OOo 3.x
The extension actually does not work with 3.x, checked with OOO300_m4. ATTENTION: It breaks the installation and the office can not be started anymore.