Difference between revisions of "Tabbed Windows Extension Discussion"

Revision as of 14:23, 18 April 2007

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 case where the target "_default" is used.)

On the other hand we already have some places in the code that always create a new window, 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 extensions leaves them untouched, e.g. they create a new top window. (For developers: these are the case 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 the pattern that the user can use 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. "Open file" always replaces the current content and the same is true for the URL input field. As a workaround Firefox offers commands to create new blank tabs or windows.

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 this 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? I don't think so.

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. I think such command better fits to the "Window" menu but people might be used to look for it in the file menu.

Managing tabs

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 anopther 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.

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.

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. Then only the docked windows of the active tab (the one having the focus) will be shown.

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. Users should also be able to create a new window from a tab.

Other known problems

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.