Re: Mac OS X UI (cocoa-dev digest, Vol 1 #581 - 19 msgs)
Re: Mac OS X UI (cocoa-dev digest, Vol 1 #581 - 19 msgs)
- Subject: Re: Mac OS X UI (cocoa-dev digest, Vol 1 #581 - 19 msgs)
- From: Ondra Cada <email@hidden>
- Date: Sat, 15 Sep 2001 01:57:32 +0200
Gary,
>
>>>>> Gary C Martin (GCM) wrote at Sat, 15 Sep 2001 00:09:40 +0100:
GCM> I can however see if you wanted key windows not necessarily as the
GCM> foremost window (as per some of your other UI suggestions)
Yes, of course! That's quite a nice thing, especially if you got a mouse
roller which allows you to scroll those front but inactive window. Until I've
tried I would not believe how much time you can save this way (compared with
the clumsy way of OS9 or Windows where you just _have_ to activate a window
if you want it foreground).
GCM> you could get users quite visually confused*.
Not really, provided of course that the key/main/inactive windows are
properly visually distinguished.
GCM> * Like currently when Mail v1.0 can't connect to the POP server and pops
GCM> an inactive alert window above all other windows while not changing it
GCM> to key focus and you end up messing with you hidden document before you
GCM> realize you have to stop key tapping and start mousing for the 'ok'
GCM> button.
Ouch, that's too bad, of course -- the change (of relative window placement)
should not be caused by some background thread; it should be _always_ caused
by user's explicit action.
On the other hand, *IF* application for some reason _must_ show an alert not
as result of my action, but as result of some background task, I would
_definitely_ prefer it not to become first responder!!! Just imagine: you are
writing something, which generally means you have, like, a few next words
already "in head"... and pop! an alert which gets first responder occurs!
Beep beep beep beep it goes as you pressed those few keys which formed the
word you just written; much worse it becomes if you just happened to want to
start a new paragraph, in which case you would close the alert without even
reading it!
No, *IF* there is alert to be shown as a result of bacground task, it *MUST*
*NOT* get first responder -- that should be left in the original text view
indeed, so as you can finish what you had started before the alert occured.
Of course, as I've written, the application should *never* pop a panel
(regardless the panel is made first responder or not) when user is supposed
to write to some editable area. It should inform the user by some other way,
which does not interfere with the writing.
(Actually, not just writing, but any action -- the very same would apply for
drag'n'dropping or whatever.)
Even in the worst case, ie. if the writing itself is invalidated by the
cause of the "alert" (like writing online in terminal, the cause being line
went down), it should be solved differently. Like, making the text view not
editable immediately (but _keeping_ first responder there), and showing the
alert (sheet would be better here) which _won't_ get first responder (lest
you close it by Enter which was originally meant to end a line in the text).
---
Ondra Cada
OCSoftware: email@hidden
http://www.ocs.cz
private email@hidden
http://www.ocs.cz/oc