Re: Modal dialog alternatives?
Re: Modal dialog alternatives?
- Subject: Re: Modal dialog alternatives?
- From: Pandaa <email@hidden>
- Date: Thu, 16 Jun 2005 15:19:37 +0200
16 jun 2005 kl. 10.20 skrev Andy Bettis:
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?
You can allow them to do both.
You can still have much of the same behaviour even when embedding the
editor in the list-window. So that e.g. there is an "add" button only
within the editor. Clearly delimiting the editor by a bordered-box of
some kind, and having slightly more descriptive names for actions
than "add" could help to avoid confusion.
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.
I think most users would know how to use Undo to get out of that, and
to assist them you could e.g. keep a per-field and per-transaction
history of values that pops-up allowing the user to easily revert to
older [or newer] values.
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).
While you can never know when the user is done typing, I'm not sure
it's a good idea to impose a strict order only to create the illusion
that you can know (which would be what a modal dialog did in this
context).
Since your error message should be non-modal in any case, why not
start to fade it in when you first detect an error? Then, if the
error is gone before your message becomes visible you cancel the
message.
You have the same problem in the modal dialog, unless you are
requiring the user to press a button to get feedback from your
validation.
The sort of dialog you're suggesting works for techie type users
but in my experience is not so good for normal human beings. ;-)
Perhaps there may be ways to extend it, and present it, which makes
it usable for both groups. Like adding clear visual indications of
which field is being edited.
I'm not sure, but it seems to me that the modal approach may be more
about avoiding the interaction problems by dictating strict orders
than actually attempting to solve them.
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.
True.
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . .
. email@hidden . . www.synapticpulse.net .
_______________________________________________
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