Re: [Evolution-hackers] [Fwd: Re: [evolution-patches] [PATCH] IMAP preauth and subcommand connection.]

[David Woodhouse <dwmw2 infradead org>]

On Wed, 2003-07-23 at 14:59, Anna Marie Dirks wrote:
> The plan discussed here seems fairly reasonable to me; I have only a few
> simple concerns.

Thanks for your input.

> > True -- if they have to look at the help text we're already doing
> > something wrong. 
> 
> This isn't necessarily true. Presumably the widgets associated with this
> command have to appear in the account setup druid as well as in this
> dialog, right?

Yes, I believe they appear in almost exactly the same fashion. The top
of the druid page in question doesn't give detailed instructions though
-- it currently just says:

	Please enter information about your incoming mail
	server below. If you are not sure, ask your system
	administrator or Internet Service Provider.


> It is standard practice to put a bit of help text at the
> top of each druid page.(Which is not to say that we necessarily should
> include info about this custom command business in the druid, but rather
> to point out that including some measure of help within the window the
> user is using is not always a sign of defeat.) 

With this I agree -- but we should definitely strive to ensure that the
user doesn't even _need_ to look at it :)

> > That's why I put in a default command which uses both
> > $URLUSER and $URLHOST, rather than leaving it blank by default and
> > forcing the user to enter _something_. It's self-documenting like that.
> 
> Hmm. The need for a custom command isn't predicated on the ability to
> understand syntax like '$URLUSER'. (Which, btw, if you read it aloud in
> English, is a homophone for "You are loser." eek. Hardly the message we
> want our users walking away with, is it. :) 

:). OK -- %h and %p it is.

> (It also concerns me a bit to put text in the entry, which if the user
> just accepts it as is, would lead to their mail setup being necessarily
> dysfunctional. I'd rather force them to type something into the entry..)

How about we do it as a combobox? Start off empty, and the drop-down box
gives a selection of commonly-used examples? That way you force them to
select something, as you desire, but the common options are easy for
them too.

(It wouldn't usually be dysfunctional if they selected the default --
the whole point in the default is it's what most users of this option
would want. I'm happy enough with it blank if you prefer, though.)

> Speaking of odd wording, in one of your earlier mails, you proposed the
> following structure for the "Connection type" option menu. 
> 
> >  Connect using' [remote host]
> >                 [always ssl]
> >                 [ssl when possible]
> >                 [command] 
> 
> I have to wonder how many average users would understand "remote host"
> in that context. 

I agree with you. Using the text 'Remote host' sounds like a very bad
plan to me.

> Further, the current UI gives some context for "ssl" by saying "Use
> secure connection". It would be nice if your UI provided some context
> for "SSL" as well. (Besides "connect using", which doesn't so much get
> the whole "this is related to security" thing across. :)

Can we assume the user understands the word 'encrypted'? If so,
something like:

	Connection type:   [ Unencrypted ]
                           [ Encrypt if possible ]
                           [ Always encrypted ]
                           [ Run custom command ]

Or perhaps

	Connection type:   [ Unsecured ]
                           [ Use Secure Socket Layer if possible ]
                           [ Always use Secure Socket Layer ]
                           [ Run custom command ]


> > > If we go this way we should be hiding the entry completely, because you
> > > don't want the default page to be clobbered with details 99% of the
> > > users do not care about.
> 
> You also, though, don't want the dialog to resize (grow larger) when the
> entry is shown. 

True. 

> Within the rest of the account druid and account editor, the way that we
> present information which is optional to the user is to desensitize it,
> until the user makes a selection which calls for it to become live-- cf
> the "Authentication" options in the "Sending Email" page of the druid.
> For consistency's sake, I would prefer that we handled the custom
> connection command stuff in the same way.

That was my original suggestion, and is my preference. I was just trying
to keep Ettore happy since he seemed to want it to disappear :)

> My recommendation for how to handle these options is therefore:

> http://primates.ximian.com/~anna/mailsettings/start.png


Looks good, thanks. Although I'd suggest making the Command: box a
combobox, so the user can select the commonly-used commands from it
without having to type them in.

Personally, I'd prefer the 'Connect using' choice to be available
without the separate and redundant 'Use secure connection' checkbox, but
I will defer to your expertise on that.

 < snip sensible suggestions #1-4 >

> Now, maybe this is way too much work, or maybe it isn't technically
> feasible to just move the authentication stuff over a page, or maybe
> <insert some other reason why this approach is nonviable here>. Maybe
> these options are really *so* esoteric that they just don't deserve the
> real estate I am giving them.

No, I think it's technically feasible and it's sensible. It is, however,
a UI cleanup which is largely orthogonal to the feature I'm trying to
implement. ;)

If the only way I can get the feature merged is to implement the
marginally-related UI cleanup, then I suppose I'll have a go at it.

But could I request perhaps that I be allowed to merge with just the UI
I suggested in my screenshot, and then when you implement the other
changes to the UI, you can call on me to sort out the command-option UI
myself if it's not trivial to do so for whoever's making the other
changes?

> In that case, what I think you should do is: try to come up with more
> simple and descriptive labels,

OK -- the way you did it in your screenshots looks good to me.

>  include the desensitized command widgets by default so that the
> dialog doesn't jump around, 

Definitely. 

> and, if you are going to include an example, include it beneath the
> "command" entry so that the user is less tempted to think that it is a
> valid command.

I disagree. The examples _are_ very likely to be valid; that's the whole
point in them. Would you be happy with a combobox, defaulting empty?

-- 
dwmw2