Re: [Usability] HIG and MDI/SDI/Tabs

["Curtis C. Hovey" <sinzui cox net>]

On Mon, 2003-09-01 at 15:25, Havoc Pennington wrote:
> On Mon, Sep 01, 2003 at 12:20:04PM +0100, Calum Benson wrote:
> > 
> > Although it's not currently very clear, the HIG is really only advising
> > against the hard-coding of such window management policies into the
> > applications... the hope is that one day, window managers will let the
> > user choose between multi-document models  (MDI, tabs, multiple top
> > level windows, anything else that's invented in the meantime) for any
> > particular application.  
> 
> I feel pretty sure that this can't or shouldn't be done in the window
> manager; it's really something that belongs in a standard GTK widget.
> 
> We'd like to see such a widget for GTK 2.6. It may also want to cover
> "IDE MDI" also which is somewhat more complex as it's not just
> documents, it also has random dockable utility windows etc.
> 
> What I'd like to see from the UI team is a recommendation for how apps
> should work in some detail:
> 
>  - web browser (read-only documents, tabs popular now)
>  - IDE (editable documents, with lots of auxiliary dockable thingies)
>  - office apps (editable documents, but no auxiliary thingies)

Office apps often a style widow/palette that is screaming to be docked.

>  - GIMP (editable documents, but many people claim it's different
>          from the office apps somehow)
> 
> What is the ideal kind of "big picture" organization of these apps,
> how does the window manager, window list, Alt+Tab, etc. fit in, 
> what is the workflow.

Before the super powers voice their opinion.  I'll sneak in a few ideas.

Firstly we need a generic way of describing/handling docking to avoid US
patent problems with Apple.  Apple patent describes tabs, but with a
generic description of a document/palette window, it may not apply since
other UIs have dockable windows.

Docking may be single-view or multi-view.  Single-view is like tabbed
browsing, only only view can be seen and interacted with at a time
(similar to a modal window).  The multi-view will show two or more views
simultaneously, like a pane, and the user can interact with them (much
like a modeless window).

Users can switch the view of a single-view by tab like a browser,
menulist like Nautilus's sidebar, window menu like MS Office apps.  The
user should set their preference using the gnome-control-center.  I
think the menu will always need to provide switching the view of a
single-view, the user should choose between tabs and menulist.

MDI has traditionally offered a cascaded or tiled view, both of which
have usability problems since the child windows can appear to be
top-level windows.  Multi-view must provide a paned mechanism.  Panes
are poorly labeled in all UI's, users must have the option in the
gnome-control-center to display window titles/pane labels.  Users must
be able to select and move a window up, down, right, or left to change
it's position in relation to the other child windows.

Child windows can be described as either a document, or a tool palette. 
There may be a need to restrict mixing document and palette views in a
single-view window.  Single-view's can be embedded in a multi-view
pane.  When a user moves a window to a single view pane, it is added to
the single-view pane and made the active view.

All apps that provides views must allow the user too switch between
single-view and multi-view from the menu--There is no global
over-ridding preference.  Moving views, having multi-views, having
single-views in multi-views, can quickly confuse the average user.  The
developer needs know the target user and be able to lock-down the app to
prevent too many views from being managed at once.  A single-view set of
pallets and a few document in multi-view might be correct for office
apps.  Restrictions are still needed for IDEs (I'm sure users of
Eclipse's view and perspective will agree).

As apps grow in their power to manage concurrent windows, users are
using more system resources.  Experienced user have learned to close
windows (because a window is the app) to make their computer more
responsive.  A good child window solution will manage system resources
so users don't need to hunt for windows/apps to close.

-- 
__C U R T I S  C.  H O V E Y____________________
sinzui cox net
Guilty of stealing everything I am.