Re: Modal dialog alternatives?
Re: Modal dialog alternatives?
- Subject: Re: Modal dialog alternatives?
- From: Andy Bettis <email@hidden>
- Date: Fri, 17 Jun 2005 15:28:15 +0100
On 16 Jun 2005, at 22:15, m wrote:
On Jun 16, 2005, at 9:16 AM, Andy Bettis wrote:
The point I was trying to make is that guidelines used to be
suggestions for how to improve your UI, which could be disregarded
if you had a good reason for doing things differently.
They still are. But my point is that if you want to swim upstream,
you should expect some difficulty. Apple is correct to focus on
making what's in the guidelines easy to do, not on making
everything that is conceivable easy to do. If you disagree, you
should file a bug.
Are you surprised that Cocoa doesn't go out of its way to support
things that are proscribed by Apple's Guidelines?
I'm surprised that something that's already in place (for alerts,
etc.) isn't finished off properly in accordance with the API
documentation. This stuff isn't rocket science.
You might also be surprised that the inability to nest modal gets
very little mention here. Draw your own conclusions. Perhaps you
truly have a unique situation which cannot be solved any other way...
... or it's easier to run with the flock than to design something
that actually fits the _user's_ needs? ;-)
But seriously, I've arrived at this situation because my existing
apps have used nested modals and my clients have liked them. If it
turns out that I can't use them in Cocoa without lots of low-level
coding then I am interested in finding different ways of doing things
that don't mean that my clients end up with what they perceive as a
less usable interface. If I can come up with something better then
everyone (including my accountant) will be happy.
BTW, which API are you referring to? NSAlert for example doesn't
support nested alerts does it?
I meant that the runModalForWindow and stopModal calls don't work
when used in nested dialogs.
As I understand it, you are using modal dialogs to implement the
"detail" part of a "master-detail" type of interface and this is
leading inevitably to nested modal dialogs. Yes?
Consider implementing your "master-detail" interface in a single
window like so:
<http://developer.apple.com/documentation/Cocoa/Conceptual/
CocoaBindings/Tasks/masterdetail.html#//apple_ref/doc/uid/
20002090-119367>
That would solve your problem and give you a cleaner interface to
boot.
This is just a modeless dialog stuck to the bottom of the window,
as I've explained elsewhere.
The details matter (I guess that's kind of a pun, sorry). The
master-detail design clearly associates the editor with the doc.
The modeless design suffers from a potential document<->editor
disconnect in the mind of the user.
Both the modeless dialog and the master-detail approach have problems
that I've explained before. See below.
Your other objections as far I was able to understand them are:
1) Real estate: There need not be any real estate compromise if
nothing is being edited (shrink the editor down when not editing).
In any case the benefits probably outweigh the costs.
2) Document state that is transiently invalid: I don't understand
this. You can enforce document consistency by only changing the
document once the edit is validated. Am I missing something key here?
By using a modal dialog for data entry the users assembles a
collection of changes and then submits them to the app. If there are
validation errors then no changes are made, otherwise the data is
updated. The dialog acts as a filter, either accepting or rejecting
the requested changes, and thus the data held are always valid. I
suppose you could say that while the modal dialog is showing that the
document is transiently invalid, however the only way that the user
can progress is by providing valid data or cancelling the whole
transaction. If the document can be saved, printed, processed or
whatever it will be valid.
This would obviously be a very irritating interface for something
like a word processor or drawing program where you want to see each
change as it is done. However the sort of apps I specialise in are
used to keep records, accounts, etc. and in these cases it is more
important to know that the contents are consistent and validated, so
that once the information has been entered the accompanying paperwork
can be filed away. Any interface that allows inconsistent or
incomplete data to be entered, or which has to assume something about
the user's intentions, is just not acceptable. I've yet to find a
modeless method of doing this, although I'd be very happy to find one.
I hope this makes my questions clearer.
Thanks for the input and the vigorous debate. Good stuff!
Rev. Andy
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden