Re: Re: CvsAlert changes

Am 12.12.2003 um 03:22 schrieb Jerzy Kaczorowski:

> Jens,
>
>> I'd prefer not to try and guess the default button, but rather
>> always have the OK button the default button.
>
> It may be a little bit dangerous. The current logic is assuming a  
> single OK
> button for a note type of message and Cancel default button for  
> question and
> error messages. The OK will be default for warnings. That choices seem  
> quite
> reasonable to me at the moment but I am open for discussion here.

I don't think it's too dangerous: after all there's already an alert  
popping up, that should be break enough to let the user reflect the  
action.
Personally, I find it most annoying if the default behaviour gets in  
the way of an efficient workflow in the majority of situations...
If a question is really critical, the calling code should know and make  
sure the default button is the cancel button, but IMHO, for most  
situations, the fact that an alert requires _some_ input is alert  
enough so users don't have to toggle away from the default behavior,  
but just can press Enter to continue.
(BTW: If users decide to not read an alert, it's their own fault, IMO!)

Think about moving a file to the trash: this is a reversible operation  
(except for maybe gCvs, which immediately removes the file), so OK is  
perfectly justifiable in that question.

And again: I'd rather avoid having the type of the alert decide which  
buttons should be default. This can create problems on the long run, if  
e.g. someone decides an alert would rather be a warning than a question  
sometime later:
e.g. someone writes code that questions "Something is wrong with your  
files. Do you want to continue importing them?" as a question dialog  
(i.e. Cancel is default). Later on, someone decides this is really a  
warning rather than a question. -> violà, the default button suddenly  
is "OK" unless whoever changes the alert type remembers this side  
effect...
In general, I think, side effects should be avoided at all costs (and  
yes, my original suggestion for platform specific default buttons is  
almost as bad a side effect :-| ).

If CvsAlert always has a specific default button (I'd vote for "OK",  
but no matter what, it should not depend on the alert type), then you  
wouldn't have to remember to adjust the default button when just  
changing the alert type...

>
>> Instead, we might introduce a subclass of CvsAlert, e.g.
>> CvsCriticalQuestion that will take a message as argument and
>> make the cancel button the default. That would be just as
>> convenient, but would leave some defined behavior in the base class.
>
> I think we don't need to make a new class for that. I have two ideas  
> here:
>
> 1. Change our kCvsAlertIconType and for example add two question types  
> to
> control the default button. That would make sense as it would indicate  
> the
> importance of the message at the calling place. But we have to  
> remember not
> to introduce too many of these to avoid confusion.
>
> 2. Create an overload or change the signature of CvsAlert::ShowAlert  
> method
> and pass the default button there. E.g. overload:
>
> kCvsAlertButtonType ShowAlert(const kCvsAlertButtonType defaultButton)
> {
>     m_defaultButton = defaultButton;
>     return ShowAlert();
> }
>
> Somehow I like the overload more that having the default parameter  
> added to
> the current method. If we used the default parameter we would probably  
> have
> to define the "neutral" alert button type to indicate that we want to  
> keep
> the one selected in constructor.
>
> Any of the above allows to override an automatically selected default  
> button
> quite easily.

Yes, (2) sounds good.
I'd just suggest to move the real ShowAlert implementation into a  
virtual protected member (e.g. _ShowAlert) and have the overloaded  
ShowAlert members call that virtual member with the appropriate default  
button parameter. In that case, the guessing of the default button  
would move to the ShowAlert() member that doesn't specify the default  
button...

>
>> P.S: I changed the Mac implementation of AskYesNo and
>> ConfirmMessage to use CvsAlert and I think this could probably
>> become cross-platform (except for a small portion in AskYesNo
>> where MacCvs makes sure the log window is visible and frontmost
>> so it can be read behind the alert).
>
> Just FYI: I am planning to eliminate the AskYesNo and place the code
> directly into the AppGlue where it's called. After all it's just a  
> couple of
> lines and doesn't deserve to be a function!
>
> I want to limit the number of functions doing essentially the same  
> thing -
> showing the alert message. The next candidate is obviously  
> PromptMessage and
> maybe even PromptEditMessage.

I wouldn't mind moving the AskYesNo stuff into the AppGlue, since  
apparently that's the only place where it's used, but please remember  
that there's some additional code in there for the Mac implementation  
that makes sure the log window is visible, not minimized and the front  
window before showing the alert, so users can actually see what the  
alert refers to. When you move the code, please make sure this goes  
along ;-)

>
>> O.k., I've conditionalized the code to set up the button titles
>> in MoveToTrash code. (Confirmation dialogs should just never
>> ask with "Yes" / "No" on the Mac according to the UI guidelines)
>
> Can you provide some link to those guidelines? (sounds like I better  
> read
> that before my next move ;)

see here:
<http://developer.apple.com/documentation/UserExperience/Conceptual/ 
OSXHIGuidelines/XHIGDialogs/chapter_17_section_2.html#//apple_ref/doc/ 
uid/20000962/CJECBHJE>

(this is the part about dialog & alert general guidelines - you can use  
the "Previous Page", "Next Page" or "Show TOC" links to see more of the  
HI guidelines)

>
> In fact if Kalle agrees we could all use the OK/Cancel for moving to  
> trash
> question. Even thought the Window OS uses Yes/No for the same I can  
> see how
> it can be more intuitive with OK/Cancel.

Whatever seems to match best with what users are used to on the  
platform, I'd suggest. As I said, alerts with "Yes" and "No" buttons  
look awkward to Mac users, just as "OK" and "Cancel" may seem strange  
in this context to Windows users (I don't know, I'm not one of them ;-)

</jum>


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges or Refill Kits for your HP, Epson, Canon or Lexmark
Printer at MyInks.com. Free s/h on orders $50 or more to the US & Canada.
http://www.c1tracking.com/l.asp?cid=5511
http://us.click.yahoo.com/mOAaAA/3exGAA/qnsNAA/NhFolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
[email protected]

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/