Re: Modal dialog alternatives?
Re: Modal dialog alternatives?
- Subject: Re: Modal dialog alternatives?
- From: Andy Bettis <email@hidden>
- Date: Thu, 16 Jun 2005 09:20:42 +0100
On 15 Jun 2005, at 16:06, John Timmer wrote:
There's more. Each transaction is assigned to a category. There is a
menu item that brings up a modal dialog showing a list of the
categories, and by double-clicking on an entry in the list another
modal dialog is displayed allowing the selected category to be edited.
Again, having the dialogs be movable means the user can see the
existing items, and anyway I believe that having sheets upon sheets is
frowned upon by Apple too.
...
So, any suggestions? I really am open to other ways of doing this, but
not at the expense of the ease of use for the user.
Well, the first thing I'd do is to disable the ability to pop up the
category editing window when there's already a modal session active.
That
cuts down the potential number of modals you can have on screen at
once.
This is actually the nub of the problem - the category editing dialog
is spawned from the category list dialog.
I'd also think seriously about the design. Although I agree that a
movable
modal will allow some information to be viewed while it's active,
think of
the flipside: if I remember correctly, you're doing a document based
application, and the user can have multiple documents open at once.
Using a
sheet allows them to examine the content of other documents while the
sheet
is active - using a modal dialog prevents that. So, you may be losing
as
much or more accessible information as you gain by going modal.
In this case it is more useful to be able to examine the parent
document than other ones, but I take your point.
As for your specific issue, is it possible to change the category
dialog so
that the editing fields are present in the same window as the list of
categories? As the selection in the category changes, you can simply
update
the editing fields accordingly, and validate the entries upon table
selection change or editing completion. If I'm not clear in my
description,
email me off list and I'll send you a screenshot from one of my apps.
I've used this method in the past and it has confused end users. There
needs to be 'add' and 'delete' buttons to insert and remove entries as
well as the editing fields. If the user changes the displayed field
contents and clicks 'add' did they mean to change the existing entry
and then bring up a blank set of fields for a new entry, or did they
think that they could put the new entry's data in and then click add to
insert it? If the user clicks on an entry in the list and starts
amending the fields and then realises that they chose the wrong one how
do they get out of it? They could use undo and make sure that they undo
all their changes but not earlier changes, or there could be a revert
button, but these are a bit fiddly. Or the user types in a duplicate
name (which is not allowed), at what point do I display an error
message? I can't do it while typing as the name being entered may not
be complete, so I have to wait until some later time to be sure that
there is something wrong, which means that the message is disconnected
from the action (if you see what I mean).
The sort of dialog you're suggesting works for techie type users but in
my experience is not so good for normal human beings. ;-) It also makes
the audit trail much easier as there is a single commit point at which
the new data replaces the old for an object, rather than a separate
point for each field.
I'll probably write a prototype app with a non-modal window for
categories and sheets for editing fields, and then see what my local
clients make of it.
Thanks for all the advice.
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