Re: Modal dialog alternatives?
Re: Modal dialog alternatives?
- Subject: Re: Modal dialog alternatives?
- From: Pandaa <email@hidden>
- Date: Thu, 16 Jun 2005 19:07:57 +0200
16 jun 2005 kl. 17.58 skrev Andy Bettis:
On 16 Jun 2005, at 14:01, Pandaa wrote:
15 jun 2005 kl. 15.51 skrev Andy Bettis:
Having non-modal windows makes the updating of data very messy.
If, for example, I had a spreadsheet-lloking table for my
transactions where users could change the data directly when do I
perform the validation?
Continuously, with a slight delay while the user types data?
Flagging the transaction and field as red or grayed out when the
data is in an invalid state, offering a short, concise non-modal
and non-distracting explanation somewhere?
But then you need to have a messages area which eats into the
screen real estate, which will be blank for most of the time and
(almost certainly) not big enough for a meaningful message when
needed. Or which contains error messages that will go away when the
user finishes editing all the fields, and so the user will learn to
ignore?
It probably shouldn't go away until the error has been resolved, but
it also doesn't need to eat into screen real estate when it has
nothing to say. How to best do this depends on your application, and
you would need to keep in mind that any number of fields may be in an
error state at any time.
Perhaps by using red-underlining of the text of the entry, displaying
a concise explanation in a grey field floating below the entry and
pop-ing up a red arrow which makes the error stand out from the rest
of the document together with a small 'go-to' like button to the far
right in the field that can be pressed for a more detailed
explanation. This is just a course idea that came to mind and would
need refinement, I don't know what would work in the context of your
application.
That would allow more than one transaction to be in a temporary
invalid state at once, which in some cases may be a more natural
way for someone to perform an edit than being forced into editing
one-whole-transaction-at-a-time.
The trouble with 'temporarily invalid' transactions is that they
put the document itself into an 'invalid' mode, so that reports,
analyses, projections, etc. can not be produced.
Is this a problem if the report, analysis and projection functions
are intelligent enough to ask wether to delay the report or base it
on the last known consistent state in the cases where this actually
happens? Also, if the invalid states is part of the short-time
workflow of a user, he or she is unlikely to wish to produce a report
of the intermediate state.
Since having temporary invalid transactions in a document would be
analogous to being inside the modal transaction editor for said
document, which would presumably also prevent a report or similar
from being produced this isn't that different from what you already
have. The same situation exists with the modal dialog.
I'm sorry if I seem to be just stubborn and bloody minded, it's not
that things have to be be done my way or not at all but that the
clients I've written systems for have been happiest with modal data
entry for stuff like accounts, bookings, etc. where entries always
have a clear state.
I can understand that, and if it is really important for the entry-
list to always be in a clear state of validity perhaps modal editing
is the best solution - buying the clarity at the cost of flexibility.
That is clearly a trade-off that would be inappropriate for typical
desktop applications whose domain does not demand such measures of
strictness and rigidness, and where user comfort and workflow
flexibility would be more important.
That said, if it's what your users want and expect... and in that
case, perhaps you could still make a slightly more open modal dialog
by using a non-modal dialog and setting your document window in a
[visually clearly indicated] 'disabled' state in which only non-
editing operations, like scrolling and viewing details can be done.
With this solution, you can get precise control over the degree of
modal-ness.
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.
Perhaps you could have the transaction-editor inside the same
window as the transaction-list, sliding up from the bottom of the
window instead of appearing inside its' own dialog? That would
allow the user to interact fully with the transaction-list while
editing an individual transaction, and could potentially make
switching between editing different fields much quicker. When the
field editor is done, it could slide down again leaving the
transaction window as it was. ( a bit like the album art viewer in
iTunes )
This is more or less the same as having a non-modal dialog, with
the problems I have explained already. With modals the document as
a whole is always self consistent, otherwise there's always some
assumption that has to be made about the user's intentions (which
is often not an area of strength for programmers!)
The document as a whole would be self consistent only if you do not
think of the modal dialog as part of the document state, which in
some real sense it could be thought to be.
It seems to me that the modal dialog already makes so strong
assumptions that going modal-less would be one of the best things you
could do to reduce the assumptions you make about the user's intentions.
( The mac-gui-dev mailing list may be a good place to ask about
questions like this. )
I looked at the ADC mailing list page and couldn't find this -
where is it?
It's a yahoo group, http://groups.yahoo.com/group/mac-gui-dev/
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . .
. 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