Re: Modal dialog alternatives?
Re: Modal dialog alternatives?
- Subject: Re: Modal dialog alternatives?
- From: Pandaa <email@hidden>
- Date: Thu, 16 Jun 2005 15:01:59 +0200
15 jun 2005 kl. 15.51 skrev Andy Bettis:
Hi folks,
After browsing around the documentation and various archives it
seems that Apple really, really don't want people to use non-sheet
modal dialogs and that there are bugs in the OS that mess up the
window ordering of multiple modals even if you do code them
correctly. Assuming this is so (and please someone tell me if it's
not) then I'd like to ask for advice in how to lay out my UI
without using modals.
I'm working on a simple accounting package. The main window shows a
list of transactions with subtotal and total lines. If the user
double-clicks on a transaction a modal dialog appears showing the
details and allowing them to be amended or deleted. Validation is
performed and updating carried out if the user clicks on OK (the
default button), the dialog just goes away if cancel is clicked. A
menu item allows new transactions to be input, in which case the
same dialog appears but with blank or default values. When a valid
new transaction is entered the fields are cleared but the dialog
remains, so many transactions can be added without needing to call
up the dialog box again and again.
In theory I could do this with a sheet. However being able to move
the input dialog away from the main window allows the existing
transactions to be viewed, which is very useful and something I
doubt the client would be willing to give up.
Does it allow to scroll the list of transactions? Does it allow to
edit several transactions at the same time? For copy-pasting between
fields or different transaction, e.g.
A sheet doesn't do this either, which may be a reason to consider
something different from both.
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.
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?
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.
If the user changes an income entry to expenditure it may be that
the associated category does not allow expenditure. If the category
is changed it may impose limits on the amounts that can be used.
Having a modal dialog means that cross-field validation can be done
when all the fields have been amended, allows for a much clearer
audit trail, and makes it very clear what has been comitted to file.
True.
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 )
Extending the embedded-editor to edit the whole selection would also
be logical, both for displaying summary information for that
selection and for fields that one may [if this makes sense in your
app] want to set to the same value for several selected transactions.
You may already have another mechanism for this, in which case it
might work to merge the transaction editor into that.
I don't know if this would work out well for your app, but it came to
mind as an alternative.
( The mac-gui-dev mailing list may be a good place to ask about
questions like this. )
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . .
. 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