Aaron Optimizer Digulla wrote:
>
> On Wed, Jul 26, 2000 at 11:35:30AM -0600, Mitch Chapman wrote:
>
> > It may be that I'm solving the wrong problem. In other words,
> > there may be a better way to present the information that's
> > currently being displayed in these modeless dialogs. But if
> > y'all have any suggestions for how to solve this specific
> > problem, I'd be grateful.
>
> The correct solution would be to fix the customer :-)
> The reason why you cannot iconify modal dialogs independently
> of your application is the human brain: Just imagine, your
> working with your app and then suddenly, one of the modal
> dialogs is in your way and you iconify it. Now you do
> what you wanted when the dialog got in your way. After
> some time, you go back to your app and try to continue
> to work with it. But now it "hangs". You try everything
> and after some time kill the app and start it again because
> you didn't remember that there was an iconified modal dialog
> which blocked the "hanging" application.
>
> Conclusion:
>
> - Don't use modal dialogs. Disable gadgets instead. This
> gives the user a visual feedback of what is going on
> unlike the modal dialogs. What you can do is you can
> disable the main window of the application. This will
> make the (non-modal) dialogs independent of it and you
> can iconify every window indepently. Also, a user
> will now see right away why he cannot work with the
> application.
Well-put, but my customer wants mode*less* dialogs.
They want to be able to continue working with the main
application after the dialog appears.
Imagine a window full of thumbnail vector images. A single
left-click on a thumbnail brings up a resizable window
showing a larger view of the window. The number of
thumbnails, and consequently the number of enlarged views,
can be quite large. That's what the current specs call for.
Here's the problem scenario: The user has clicked on a
thumbnail and gotten a larger view. Now the user wants to
go back to the main window and click on another thumbnail
to get another larger image to compare to the first. As soon
as they click on the new thumbnail the main window comes
forward, obscuring the original thumbnail.
You and I know that, with most window managers, you can just go
back to the taskbar and bring the original zoomed view forward
again. And our users know that, too. But in practice I've seen
them get confused (not to mention annoyed) when their original
zoomed view "disappears".
The most obvious solution is to make the zoomed views transients
for the main window, so they always stay in front of it. But
this would force the user to keep dragging the zoomed views out of
the way, so they could see enough of the main window to get at
other thumbnails. Hence (I think) the request to make the zoomed
views stay in front of, but be separately iconifiable from,
the main window.
We need to look at the usage scenarios in more detail. For
instance, if the users tend to view only two or three zoomed
views at a time, then it might not be so annoying to make
them transients for the main window. Screen real estate being
what it is, I can't imagine them trying to look at very many
zoomed views at once.
But a completely different solution might be much better. This
is what you're saying, and is also what I meant by "solving the
wrong problem."
For instance, since users seem to be trying to compare zoomed images,
it might make sense to grid the views into a zoom "dock", one which
comes forward every time its content changes, but is not a transient
for the main window. This would let the user create comparative
views without manually dragging modeless dialogs into position, and
would also get around the problem of screen-blocking transients.
Guess it's time for another prototype. Thanks for helping
trigger some ideas.
--
Mitch Chapman
[EMAIL PROTECTED]
_______________________________________________
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
