Re: Launching vs. Raising an application...

[Tim Moore <tmoore tembel org>]

Ami Ganguli wrote:
> 
> I was playing with Gnome for this first time today and suddenly had
> a GUI revelation.  I figured I'd subscribe to this list to see if
> anybody
> agreed with me.
> 
> Anyway, I once taught beginning computing courses at various
> private training companies and I've seen lots of newbie users trying
> to figure out the MS-Windows user interface.

Just curious: was this a problem with Windows95 users? Or just Windows
3.1? I've heard a lot about this problem before, but always in the
context of Windows 3.1 where the minimized app icons and the program
manager icons were so similar. This was why MS replaced them with the
taskbar and Start menu respectively. Do people confuse those, too?

> A common problem is confusion between launching and application
> and raising/maximizing an application that's already open.  I've
> often found users having trouble because they'd somehow opened
> a dozen or so copies of the same program.  New users find it intuitive
> that in order to get back an application that has "disappeared" (i.e..
> you've minimized it or hidden it behind a window)  you repeat
> whatever you did to start the thing in the first place.  Why not
> try to blur or eliminate the distinction between minimized and
> terminated applications?

Not a bad idea, but we should be thinking in terms of windows, not
applications. To me, windows usually represent something like a document
or a tool, whereas applications are chunks of code that are better
ignored by most users.

> 1/  Each Gnome app creates a PID file when it starts.  If a previous
> PID file exists, check if the process is really running and take some
> action to maximize it, as this is probably what the user wants.

The problem is application != window. They don't map 1-to-1.

> 2/ Each Gnome app should include a menu option to "Open another
> window" (as in Navigator).  This would provide the ability to
> launch another instance of an application.

This, I think, is an area where user testing is in order. Most of the
time, when I open a program from a launcher/menu/whatever, I want it to
do the same thing each time: open up a new window. I don't know what
most people are expecting.

IMO: one of the reasons this is a problem on Windows is because of MDI,
which I hate with a fiery passion. :-)

> 3/ Minimized apps could simply disappear.  No desktop icons.
> The 'right' way to find the application again would be to select
> it again from the menu or panel.  To make things easier, a panel
> applet could be created with Icons for the 5 (or so) most recently
> used applications.

But how do you deal with multiple windows in an application?

For example: how do I make one of five Netscape windows appear without
maximizing all of them?

> 4/ Have applications save state and exit when they are minimized.
> As long as the application properly saves state, there need not
> be a distinction between exiting and minimizing a window.
> Perhaps there should be a time-out period: after five minutes of
> being minimized, the application saves state and exits.  (I realize
> there are lots of applications where this would be a bad thing -
> a cd roaster comes to mind.  Only apps where this actually makes
> sense would do such a thing.  Actually, this could work with a
> CD-roaster too, as long as it could enter a "don't exit" state
> while it was actually roasting.)

Or anything with a slow startup. Of course, we should be eliminating
slow startup times anyway, right? :-)

> 5/  Since users will no longer be conscious of what's running,
> there is a danger that they'll shut down X while an application is
> busy (again the CD-Roaster comes to mind).  Apps that don't
> want to be accidentally interrupted could "spin" a panel applet
> (just like the Netscape spinner).  There would only be one
> spinner that's shared by all Gnome applications. Perhaps clicking
> on the applet would give status information.  Note that this
> should be used judiciously - if every app spins it while doing
> anything at all, it'll get irritating and no longer convey useful
> information.

They should still be able to shut down X and have the process keep
going. The CD-Roaster really should just be a GUI frontend on a
background task. If the GUI app dies, the background task should keep
running until it finishes. If X comes back up before the roaster task
finishes, the GUI frontend should continue to show the progress. If the
task finishes first, the GUI frontend should reflect that.

Tim